Bug or not: IPSec and OpenVPN bind to wrong IP on WAN with virtual IPs (2.4.4-p1)
-
I'd like to understand if I'm running into a bug or not, the issue has come up when updating an old pfSense 2.0 to 2.4.4 (via 2.3.5) which otherwise was pretty straightforward beyond pfSense to my surprise beyond some minor nits (i.e. changing from SHA1 to SHA256 on OpenVPN server side).
What I encountered:
- pfSense has a default gateway on an OPT (not WAN if that matters, for historic reasons) where IPSec and OpenVPN should bind to.
- OPT interface has a /29 of IPv4 addresses, the first IP is the interface IP, the other 3 are configured as virtual IPs
- Both OpenVPN and IPSec were configured to use the interface address, however generated config always started those service on the first virtual IP (only ralized when playing with sockstat and checking /var/etc)
- If the first (or any other) virtual IP was explicitely configured, the IP defined in the GUI would also be the one both devices would bind to.
The current workaround was to move IPSec and OpenVPN to one of the virtual IPs, fortunately only 2 virtual IPs were in use so 2 services could be moved to one free IPv4 address.
Although 2.0 was really outdated, before upgrading it would bind IPSec and OpenVPN to the interface IP, not the first virtual IP and not on 2.4.4 it does not generate according configs.
IMO this looks like a bug, but I'd first like to confirm this and if I can provide some extra debugging or config.xml snippets, I'm all game.
-
Based on what you have described it sounds like it was working incorrectly and is now working correctly. So if anything it was a bug that has been fixed.
Unless I'm reading the description wrong.
If so provide screen shots of the OPT inerface configuration, VIP configuration, the VPN binding configuration, and the proof it's binding to a different address.
-
Hi
It wasn't as easy to describe but I might have to rephrase and thus let me add some more data,
it's actually the other way: Worked as expected previously, doesn't work as expected after the updated.I thought it was easier to show XML/config and shell example instead of screenshots, I hope this is OK as well.
However the forum software detected all code sections as spam, so I had to resort to github gists instead:I've snipped the config.xml parts about the OPT IPs, the virtual IPs: ifconfig
This results in the following (shortened) ifconfig
First: Known-good config
- Now for the known-good/working way when I select (any) virtual IP to bind OpenVPN to on WAN_<removed>, this is the resulting part of <openvpn-server> section in config.xml
- This in turn results into the following OpenVPN config (in this case /var/etc/openvpn/server1.conf)
- And you can see, the output of sockstat confirms that it does bind to the right IP.
Problematic case: Binding to the OPT's IP:
Now for the (to me) problematic example when I select WAN_<removed> as Interface...
- First the <openvpn-server> part of config.xml, there you can see that no Address is defined.
- This however results into the following server1.conf for OpenVPN.
- And sockstat confirms that indeed, even though you can see the difference in config.xml, the OpenVPN server does not bind to .250 which is the WAN_<removed>'s address.
I could repeat that with the IPSec server but it is repeatable with both IPSec and OpenVPN.
-
Hi
I wanted to ask about where to look at further. The workaround works and since then I have (for sole fun) tried to reproduce this on a fresh system with a main and a secondary virtual IP but have not been able to reproduce it.
It has been reproducible though on this particular setup that has been update from 2.0.3 via 2.3.5 to latest 2.4.4-p1.
