OpenVPN "topology net30" broken in version 2.3.14 #1314

Closed
fraenki opened this Issue Dec 21, 2016 · 12 comments

Projects

None yet

4 participants

@fraenki
Member
fraenki commented Dec 21, 2016

This was already reported on the forums. The updated FreeBSD port security/openvpn removed a fix for the "topology subnet" option, but according to the release notes this option was only fixed for FreeBSD 11, not FreeBSD 10.

In my tests OpenVPN 2.3.14 does not work on OPNsense 16.7.11; clients can connect, but no traffic gets through. Only downgrading to OpenVPN 2.3.13 solved this issue for me.

# pkg delete -f openvpn
# pkg add -f https://pkg.opnsense.org/FreeBSD:10:amd64/16.7/MINT/16.7.10/OpenSSL/All/openvpn-2.3.13_1.txz

I'd suggest to either downgrade to the working version of OpenVPN for OPNsense 16.7.x or try to incorporate the old patch for OpenVPN 2.3.14 on FreeBSD 10.

@fichtner
Member
fichtner commented Dec 21, 2016 edited

Oh, let's see what we can find out.

@fraenki
Member
fraenki commented Dec 21, 2016 edited

Update: Actually I was referring to "topology net30" in my setup, but I don't know the configuration of other affected users. So this issue may only show up when using "topology net30" and not "topology subnet".

@fraenki fraenki changed the title from OpenVPN "topology subnet" broken in version 2.3.14 to OpenVPN "topology net30" broken in version 2.3.14 Dec 21, 2016
@mandree
mandree commented Dec 21, 2016

The FreeBSD port security/openvpn 2.3.14 did not remove the fix, instead, the fix had become part of the upstream release, and it set an 'external' p2p address on the tun interface so that FreeBSD 11+ would no longer set up wrong routes in "topology subnet" that cause traffic to go to lo0 instead of tun*.

@mandree
mandree commented Dec 21, 2016

The code was touched on all versions, only FreeBSD 11 routes traffic for one's own P2P address through lo0 instead of through tun*.
Also don't jump to conclusions or revert upstream patches, please analyse this thoroughly. Check and provide server and client side of netstat -rn and ifconfig with a "working" and "broken" version, and please do not use any patches or machine edits that change any .h or .c files.

@cron2
cron2 commented Dec 21, 2016

@fraenki if you are who I suspect you are, we can discuss this on #spassnetz tomorrow (thursday)... :-)

The "they took it out!" patch is from me and I'm really puzzled why 2.3.13 should be different to 2.3.14 on FreeBSD, with topology net30 - the patch only affects subnet, and the "net30" code has not been changed since 2008... (and my FreeBSD buildbots do test with net30, and pass traffic fine).

@fichtner
Member
fichtner commented Dec 21, 2016 edited

Thanks for everyone participating in this. It's highly appreciated. :)

We have production systems that use this since a week. My choice is to trust a minor reliability and security fix release so we bumped 2.3.13 to 2.3.14 after a lab test. And now this simply needs to be resolved without going backwards.

I can't say for sure this doesn't happen because of the way we configure the interfaces although it's odd that it manifests during a 2.3.x transition. It's pinned down to two commits and already confirmed:

opnsense/ports@72b9771

OPNsense did not use FIXSUBNET option that was 2.3.13_1 in FreeBSD because it seemed like a change that needed further testing, see:

opnsense/tools@02c55a0

Cheers,
Franco

@cron2
cron2 commented Dec 21, 2016

I really need to see logs (--verb 3 or 4) to understand how that fix can ever affect topology net30, or how it can break things. Without it, topology subnet is subtly broken on all versions of FreeBSD I tested (7.4 up), and completely broken on 11.0 - and it does not touch the code for net30.

@fraenki
Member
fraenki commented Dec 21, 2016

Thanks all. I'll send all required debug information to @cron2 on thursday or friday.

@mandree
mandree commented Dec 22, 2016

Please share the information publicly if possible (for instance you, can attach files here), or on Gist or upload it somewhere where it will stick around for sufficient time.

@fichtner
Member
fichtner commented Dec 22, 2016 edited

Got a stock OpenVPN 2.4-RC2 now to test against as well thanks to @mandree (OpenSSL/amd64)

# pkg add -f https://pkg.opnsense.org/snapshots/liblz4-131.txz
# pkg add -f https://pkg.opnsense.org/snapshots/openvpn-2.4.r2.txz
@mandree
mandree commented Dec 22, 2016 edited

The stock FreeBSD port preview has been updated with the TUNNELBLICK option re-enabled (but not run-time tested), get it and the openvpn23 siblings at https://people.freebsd.org/~mandree/openvpn-2.4-rc2-v2.tar.xz - The upstream OpenVPN 2.4.0 release is currently scheduled for 2016-12-27, the port should follow soon after.

@fraenki
Member
fraenki commented Dec 25, 2016 edited

I did extensive debugging, but out of a sudden this issue is no longer reproducable. No matter if I use 2.3.13_1 or 2.3.14 (both OPNsense versions) the VPN access works as expected. Also the configuration file did not change (I diff'ed the pre-upgrade and new config file). Previously this issue could be reproduced with basically all OpenVPN clients (on Linux, Android and Windows).

Looks like this issue was related to the OPNsense upgrade. It's strange, because the OPNsense appliance rebooted after the upgrade, so it's not possible that an old OpenVPN process was still running. I have no idea what exactly caused this issue in the first place.

I'm sorry to have caused all this buzz. On the positive side I think it's great how OpenVPN maintainers have reacted to this possible issue – really appreciated! Keep up the good work!

@fraenki fraenki closed this Dec 25, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment