WAN Static IP sets incorrectly on reboot after upgrade from 2.4.5
Hello-- We upgraded from 2.4 to the current 21.05 yesterday and I just got done fixing an issue that reverts upon reboot with the WAN IP binding to the wrong IP address. Details here:
Our WAN IP is set to X.X.X.18 / 28 with a gateway set at .17 all under 'Wan Interface - Static IP settings. We then have a OpenVPN Site to Site using .20 which binds to a port on .20 and works perfectly upon reboot. The initital indication that something was wrong was our Second OpenVPN instance which is set to bind to our WAN Interface at .18:1194 was not responding to our remote clients.
Upon further investigation, through the 'Status-Sockets' interface, I could see that there were 2 instances of OpenVPN. One on .20 and another also on .20 (when it should be on the 'WAN' interface, which is .18.)
Further research showed that the actual dashboard showed 'WAN" as .20 and not .18, even though the interface WAN settings screen had WAN as X.X.X.18 / 28 (.18)
To fix, I have to take reload the WAN interface (make a setting change and then change it back, ) and then Stop the OpenVPN instance and restart it.
The issue appears to be that Pfsense is not properly setting the 'WAN' interface on reboot, even though the settings are correct. Anyone else have this issue or a fix I can put in so it persists through a reboot? If not, I hope the steps above will help someone else. Look at the 'WAN" IP on the dashboard first to verify it does not match the interface settings like it is in my case.
Thanks in advance for any advice,
Looks like you're hitting this: https://redmine.pfsense.org/issues/11545
Are you able to test a 2.5.2 snapshot?
@stephenw10 Exactly correct, that appears to be it. I believe the issue is larger than just IPSEC and OpenVPN. It appears to be the actual 'WAN' IP that is being set incorrectly. In my case, I can see on the pfsense 'dashboard' Interface widget that WAN IP shows incorrectly. It shows as another public facing IP we have in the block that we use for other services. My installation is not good for testing as it is mission critical, but I will see if I can reproduce on my home Netgate appliance and report back to test if I can.
If you are hitting that it mostly affects VPN tunnels using the interface address. Whatever nuance it is causes the interface to return a VIP as the primary address. However you will find it doesn't cause a problem for pf using the system alias 'WAN address' for firewall rules or outbound NAT for example.
If you can use a VIP there instead of the interface address that will be unaffected.