Opened 8 years ago

Closed 3 years ago

#435 closed Feature Wish (fixed)

rampant retries can nail openvpn servers

Reported by: jhaar Owned by:
Priority: minor Milestone:
Component: Generic / unclassified Version: OpenVPN 2.2.2 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:


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


Change History (4)

comment:1 Changed 8 years ago by Samuli Seppänen

What version of OpenVPN does the Chromebook OpenVPN client use?

comment:2 Changed 8 years ago by jhaar


comment:3 Changed 3 years ago by tct

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.

comment:4 Changed 3 years ago by tct

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.