Project

General

Profile

Actions

Bug #1698

closed

IPSec tunnel from CARP backup interface

Added by Michele Di Maria almost 13 years ago. Updated over 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
IPsec
Target version:
-
Start date:
07/20/2011
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:
All

Description

Hello,
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?

Thanks,
Michele

Actions #1

Updated by Chris Buechler almost 13 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.

Actions #2

Updated by Michele Di Maria almost 13 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.

Actions #3

Updated by Ermal Luçi about 12 years ago

This needs to teach racoon about carp interface status.

Actions #4

Updated by Ermal Luçi over 9 years ago

  • Status changed from New to Feedback

This should work properly on 2.2

Actions #5

Updated by Jim Pingle over 6 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF