Opened 8 years ago
Closed 2 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: | |
Cc: |
Description
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
Change History (4)
comment:1 Changed 8 years ago by
comment:3 Changed 3 years ago by
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 2 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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
What version of OpenVPN does the Chromebook OpenVPN client use?