OpenVPN Support Forum

A simple fix with iptables DNAT (see my other post).

BTW, it's probably obvious, but you don't want to mix other traffic on the same port; a bad UDP packet will terminate the OpenVPN connection.

I haven't traced down the problem entirely, but it seems that a stray UDP packet from the right IP to OpenVPN can tear down the OpenVPN connection (I got some messages about a handshake failing, or a checksum being wrong). Since OpenVPN seems to bind to *:portnum, it seems such a packet could arrive on any interface and tear down the connection.

In many cases, the computer continues to work, which may be a security problem if you fail to notice the teardown, because you're suddenly not VPN'd. If you're on an untrusted network, this is bad.

If you could give us more details, this is something we'd definitely be interested in fixing asap. We're getting ready to roll out beta4 for 2.2, and we'd like to address this issue ASAP.

I tried to use UDP/53 as the OpenVPN port. While doing a large rsync over SSH over OpenVPN transfer, I got several of these, which are similar to what I was seeing before:

Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #9940 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

It seems to me that the DoS I was noticing before may have been on another system with an older OpenVPN. Possibly you've changed this condition from an error to a warning here, or changed a threshhold that makes it not kill the connection.

Funny that I don't seem to get them nearly as often when using other ports; I seem to get about one every four hours using the normal OpenVPN port, but got four in a minute using UDP/53.

I've ruled out "stray UDP traffic" as a cause.

Originally I thought it was because openvpn was binding to *:53, and resolver was doing DNS lookups, and somehow this was confusing openvpn and causing it to think a replay was happening.

Well, I actually am doing nobind, so the local port isn't 53. I tried hitting the local port with some UDP traffic from localhost, and that didn't stop my connection.

Also, I did a number of DNS lookups, hitting 127.0.0.1:53 (I run a local DNS cache), and this didn't terminate my connection, so that's not it either.

But it's possible that the WAP to which I'm connected is doing something stupid with DNS, or what it thinks is DNS. Just like ISPs doing transparent proxying, perhaps this WAP is trying to do something too clever with DNS. Adding to my suspicions are the fact that WPA supplicant is doing weird things, going from completed -> associating -> disconnected -> associated -> completed much more often than usual.

So, unless you hear otherwise, you can assume this was solved by making the "bad packet IDs" non-fatal, or was otherwise fixed by 2.1.0. Thanks for having taken my initial, very spotty report seriously; I appreciate it.

moved to server administration