Bug #7776
closed
IPSec reconnects after changing virtual ip address settings
0%
Description
Hello,
we are using pfSense 2.3.4-RELEASE-p1 with CARP HA.
After deleting, modifying or adding new virtual ip addresses as IP v4 alias we recognize that some, but not all IPSec connections are reconnecting (phase 1).
We did not tested if the issue is limitied to IP aliases or also occours while setup a IP address with a dedicated CARP ID.
There is no pattern regarding the used CARP device or the IP v4 addresses. Even clicking the button "Save" on existing addresses without making any changes interrupts some IPSec connections.
The modified ip address is not part of the ipsec configuration.
It this just an normal wanted behaviour of pfSense, because there are technical depedencies between the ip management service and the ipsec daemon?
Or could this be a bug?
Actually we are a little bit scared about this behaviour as the issue occured within business hours after deleting old ip addresses and the affected customers recognized the outage.
As a workaround we will schedule such tasks to a timeframe outside of normal business hours to avoid vpn tunnels are disconnecting.
Of course this is not a acceptable situation as we can make changes inside business hours.
If needed i can provide more detailed information to our configuration.
Best regards
Updated by Jim Pingle almost 8 years ago
- Category changed from Interfaces to IPsec
- Status changed from New to Not a Bug
If you modify a VIP, is it removed and readded to the interface. That could cause a tunnel attached to that VIP to drop if it happens at the wrong moment, presumably, but not 100% of the time as it may happen fast enough that strongSwan doesn't care. If you add/delete/modify a VIP that uses some other VIP as a parent, the parent isn't touched, so I wouldn't normally expect that to be a problem, but it's still possible in just the wrong circumstances.
At least on 2.4 with some light testing, I wasn't able to cause a reconnect to happen no matter what I did to a VIP, even a VIP used as an IPsec endpoint.
So either the behavior is already improved on 2.4, or it's somewhat expected. Either way, I don't see anything we can do here. Even if it were an issue, it's not something we're doing intentionally, it would be an issue in strongSwan.