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.
Oh, let's see what we can find out.
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".
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*.
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.
@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).
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 did not use FIXSUBNET option that was 2.3.13_1 in FreeBSD because it seemed like a change that needed further testing, see:
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.
Thanks all. I'll send all required debug information to @cron2 on thursday or friday.
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.
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
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.
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!