Regression #11545
open
Primary interface address is not always used when VIPs are present
0%
Description
If you have IP Aliases on a WAN interface that a Site to Site IPSec tunnel is riding over and upgrade from 2.4.5p1 to pfSense Plus, you have to go into the WAN interface and hit "Save" and "Apply Configuration" then restart the IPsec service to bring tunnels up post-upgrade. Otherwise IPSec will never connect no matter how many times you cycle the service.
Step by Step:
1. Create IPSec on WAN interface with several IP Aliases
2. Upgrade to 21.02/21.02p1
3. IPSec is broken, so you go into the WAN interface, hit save with no changes, and Apply Changes.
4. Restart IPSec service
Tunnels now work.
Related issues
Updated by Steve Wheeler 5 months ago
- Category changed from IPsec to Interfaces
- Target version set to Plus-Next
This appears to be a more general issue that can affect IPSec.
In some situations the interface can start to use a VIP IP as the primary address. That causes things running on the interface to fail as they use the wrong address.
I have seen that with an OpenVPN server.
You can see by checking Status > Interfaces.
Resaving the interface corrects the IP allowing services to start.
Updated by Viktor Gurov 5 months ago
Could be the same issue as #5999 (service takes the first IP address on the interface, instead of a non-VIP address)
Updated by Jim Pingle 5 months ago
- Tracker changed from Bug to Regression
- Project changed from pfSense Plus to pfSense
- Subject changed from Upgrading from 2.4.5p1 to 21.02/21.02p1 with IP Aliases on a WAN interface causes IPSec issues to Primary interface address is not always used when VIPs are present
- Category changed from Interfaces to Interfaces
- Target version changed from Plus-Next to CE-Next
- Affected Plus Version deleted (
21.02) - Affected Version set to 2.5.0
Sounds more like a new variation or regression of #3997
Doubtful that this is specific to Plus, so moving to pfSense.
Updated by Jim Pingle 5 months ago
- Related to Bug #3997: get_interface_ip() returns first IP on interface, not necessarily primary IP added
Updated by Jim Pingle 5 months ago
- Target version changed from CE-Next to 2.5.1
Should at least take a stab at this to see if we can come up with a workaround for now.
Updated by Renato Botelho 4 months ago
- Target version changed from 2.5.1 to CE-Next
Not enough time for 2.5.1
Updated by Kris Phillips 2 months ago
Ran into this again today on a pfSense Plus 21.02.2 upgrade. Had to do the following to fix it:
1. Save the VIP being used by a VTI tunnel without making changes and apply
2. Save the IPSec tunnel using the VTI tunnel
3. Stop and Start the IPSec service
Otherwise the IPSec service would simply say "acquiring job X" and then the "no trap found" for VTI tunnels because of strongswan puking on non-tunnel mode tunnels. No traffic was being generated by the interface at all in a pcap and the IPSec service simply puked before it even start generating traffic.
Easy workaround, but annoying and we should track down what is causing the VIPs to not properly re-tie to the IPSec service.
This affects both OpenVPN and IPSec. May also affect Wireguard depending.
Updated by Steve Wheeler 2 months ago
This only seems to affect VPN tunnels where I assume the interface IP is read directly from the interface causing the problem.
It does not affect outbound NAT for example, where the translation address remains the configured WAN IP and not the incorrect primary interface address.
Updated by Viktor Gurov about 2 months ago
Updated by M Felden about 2 months ago
I believe I am seeing this now after upgrading 2.4.5-p1 -> 2.5.1-CE with FRR BGP where FRR is told to use the WAN IPv6 address to establish BGP sessions but it chooses an IPv6 VIP for outbound communication instead. This is rejected by the peer and the session fails. Consequently it brings down all IPv6 because the Virtual IP in question is part of the prefix announced by that BGP session. Removing the IP alias and rebooting will bring us back to normal.
Updated by Kris Phillips about 1 month ago
M Felden wrote:
I believe I am seeing this now after upgrading 2.4.5-p1 -> 2.5.1-CE with FRR BGP where FRR is told to use the WAN IPv6 address to establish BGP sessions but it chooses an IPv6 VIP for outbound communication instead. This is rejected by the peer and the session fails. Consequently it brings down all IPv6 because the Virtual IP in question is part of the prefix announced by that BGP session. Removing the IP alias and rebooting will bring us back to normal.
Hello M Felden,
Per my previous redmine reply, you only need to resave the VIP and interface. There is no need to remove it, although that is a valid solution as well.
Updated by M Felden about 1 month ago
Per my previous redmine reply, you only need to resave the VIP and interface. There is no need to remove it, although that is a valid solution as well.
Hi Kris,
This workaround works but does not persist reboots and certain service restarts seem to break it, too. I can get the box up like this but it is very fragile.