Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenVPN "topology net30" broken in version 2.3.14 #1314

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

Comments

Projects
None yet
4 participants
@fraenki
Copy link
Member

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

This comment has been minimized.

Copy link
Member

commented Dec 21, 2016

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

@fraenki

This comment has been minimized.

Copy link
Member Author

commented Dec 21, 2016

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 OpenVPN "topology subnet" broken in version 2.3.14 OpenVPN "topology net30" broken in version 2.3.14 Dec 21, 2016

@mandree

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

commented Dec 21, 2016

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member Author

commented Dec 21, 2016

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

@mandree

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

commented Dec 22, 2016

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

This comment has been minimized.

Copy link

commented Dec 22, 2016

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

This comment has been minimized.

Copy link
Member Author

commented Dec 25, 2016

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
You can’t perform that action at this time.