rampant retries can nail openvpn servers

[jhaar]

I was just trying out the Chromebook openvpn client against a openvpn-git server (ie master gid version dated Aug 25)

There is an issue with the Chromebook client where it fails to parse/understand the CA pukey and when it successfully connected to the openvpn server, it rejected the connection because it claimed the cert was bad (SSL3_GET_SERVER_CERTIFICATE:certificate verify failed)

Anyway, that isn't the problem. The problem was that the client IMMEDIATELY retries and went into a loop where it NAILED the server will all these valid connections - all doomed to fail. Major CPU use, major syslog I/O

This is with "tls-auth" so obviously that couldn't help - this is exactly the kind of thing tls-auth is designed to protect - but of course this is a valid client.

So I was thinking of reporting this to Google (ha!), but I thought this is bigger than their implementation. I really can't think of any reason why *any* openvpn client should *ever* immediately retry in this situation - I mean, if it failed now, it's extremely likely to fail again in 0.1sec time. So how about just putting something like a 2-10sec sleep on fail? Just something to slow down the DoS ;-) I can totally understand why it needs to retry: you may have several servers behind one dns name and only one has a broken cert - that kind of thing. But a 2-10sec delay wouldn't do any harm...?

If it was "hardwired" into the code, then it would eventually end up on Chromebook of course ;-)

PS: got the Chromebook "working". Disabled peer validation :-(

Thanks for listening

Jason

[Samuli Seppänen]

What version of OpenVPN does the Chromebook OpenVPN client use?

[jhaar]

IV_PLAT=Chrome_OS
IV_PLAT_REL=6158.70.0
IV_VER=2.3.2

[tincantech]

OpenVPN 2.4 now has:

--connect-retry n [max]

Wait n seconds between connection attempts (default=5). Repeated reconnection attempts are slowed down after 5 retries per remote by doubling the wait time after each unsuccessful attempt. The optional argument max specifies the maximum value of wait time in seconds at which it gets capped (default=300).

I'll test that this corner case is mitigated.

[tincantech]

I have tested this and --connect-retry kicked in as expected. The server was no longer hammered by the client.

My test included, with multiple --remote servers:

• Client with correct --tls-auth but incorrect certificate
• Client with correct --tls-auth but incorrect --verify-x509-name

Both worked as expected and the client backs off retries,
as per default --connect-retry