IPSec tunnel from CARP backup interface
|Affected version:||All||Affected Architecture:||All|
it happens this. When I create a IPSec tunnel I set as interface a CARP ip address in order to let the tunnel work with both machines. If the primary machine fails the backup machine will initiate the IPSec session using the shared IP. This has undoubt advantages managing IPSec VPNs, expecially when you have to deal with other companies that can't change your endpoint easily or that can't manage a "failover double endpoint".
What happens is that the secondary machine is trying to negotiate the IPSec session all the times, even if the interface choosen as local endpoint is a CARP interface in backup state. Actually the only real problem of this is "annoying" the remote endpoint (in case they have a IDS installed can bring to ban the primary ip of the secondary machine or the network), then just in principle, this is an operation that the secondary machine should not do... this is why I set a low priority on this issue.
Do you think that would be useful for the IPSec service to check if the local endpoint is a "backup state interface" then just ends the attempt to establish an IPSec session?
#1 Updated by Chris Buechler almost 2 years ago
- Priority changed from Low to Normal
- Affected version changed from 2.0 to All
this is generally a non-issue because nothing will try to bring up the connection unless it's failed over. But hopefully in a future version we can put a proper check in racoon or elsewhere to prevent that from occurring. This has the potential to impact other parts of the system, it would be ideal if a general fix to prevent a system from sending out anything on a CARP IP with anything other than master status.
#2 Updated by Michele Di Maria almost 2 years ago
Yes, there's no impact on the local systems, it's just a matter of bothering the remote system with continuous requests that will fail because they do not match with the running active machine.
Anyway, yes, this is not urgent, I agree to postpone for a future release, or in the while to think about a general solution that will solve the same issues also on other features of pfSense.