Project

General

Profile

Feature #1965

Support Multiple IPsec Peers

Added by Jim Pingle over 7 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Ermal Luçi
Category:
IPsec
Target version:
-
Start date:
10/17/2011
Due date:
% Done:

0%

Estimated time:
12.00 h

Description

In the future it would be nice to have IPsec allow connections to/from multiple peers for the same tunnel, for failover.

racoon can handle multiple phase 1's in this way, there would just need to be some means in the GUI to allow the input of additional peers.

At least to start, it should be sufficient to have a rowhelper or similar for peer addresses and have the backend code figure out how to translate that into racoon's config.

filterdns may need some changes to accommodate this as well.

Associated revisions

Revision 27a79802 (diff)
Added by Seth Mos about 7 years ago

Add a virtual IP field to a interface in the gateway groups edit screen.
Redmine ticket #1965

Revision ab1112da (diff)
Added by Seth Mos about 7 years ago

The gateway groups array now knows about vips to be tied into that gateway group so we can tie the groups into services.
Redmine ticket #1965

Revision 3e1eec58 (diff)
Added by Seth Mos about 7 years ago

Allow for selection of a gateway group as a interface to monitor
Redmine ticket #1965

Revision bf001dec (diff)
Added by Seth Mos about 7 years ago

Allow for failover DynDNS hostnames.
replace get_real_interface() calls with get_failover_interface. If it isn't a group we call get_real_interface() anyhow.
We can't put the logic inside get_real_interface() as this would create a recursion
Redmine ticket #1965

Revision 6dbffeda (diff)
Added by Seth Mos about 7 years ago

Add Gateway Group support to the IPsec interface drop down.
Edit of gateway group correctly reflects the new IP Address.
We need to make a blacklist for interface names in the gateway group edit page.
Redmine ticket #1965

Revision b013b81e (diff)
Added by Seth Mos about 7 years ago

This script update the Dynamic DNS registration when called by apinger if a gateway from a group is down.
redmine ticket #1965

Revision 56a0c737 (diff)
Added by Seth Mos about 7 years ago

Eject duplicate script, we already have a script specifically for this.
Redmine ticket #1965

Revision 83d807cb (diff)
Added by Seth Mos about 7 years ago

Trigger dyndns and ipsecdns updates through check_reload_status. IpsecDNS already performs a filter_configure() too.
Redmine ticket #1965

Revision 8275ea28 (diff)
Added by Seth Mos about 7 years ago

Reverse the arguments, i got them wrong.
Redmine ticket #1965

Revision 47c48e28 (diff)
Added by Seth Mos almost 7 years ago

Check in code that allows for using a gateway group as the interface on the OpenVPN server page. Only allow IPv4 gateway groups for now. We'll need to add IPv6 suppport here later when we import OpenVPN 2.3.
Unbreak the gateway group function on broken configurations like a missing 3G stick.
Unbreak the interface IP/IPv6 code in openvpn.inc, we can listen on IPv4 or IPv6, not both. That path is now seperate which should cause less grief down the line.
Adds to Redmine ticket #1965 which was for the IPsec failover.

History

#1 Updated by Michele Di Maria over 7 years ago

It looks a duplicate of this:
http://redmine.pfsense.org/issues/1548

Actually this is explained better :D

#2 Updated by Jim Pingle about 7 years ago

#3 Updated by Jim Pingle about 7 years ago

More importantly would be a feature to at least have a "secondary wan" (Or a Gateway Group?) to use if the primary goes down. Brainstorming a bit how that would work, when the primary goes down it would have to:
  • Remove the static route from the failed WAN and activate it on the working WAN
  • Switch my_identifier for the phase 1 as needed in racoon.conf if set to use "my ip address"
  • Reload the tunnel
  • Anything else?

#4 Updated by Chris Buechler about 7 years ago

The biggest challenge is getting both ends to switch over correctly, as the remote would have to change its IP too. Failover dyndns could potentially help there. The above hack w/DPD is highly unlikely to be reliable, far too prone to false positives. DPD removals will happen on occasion on a functional connection, that can't be relied upon as a failover detection mechanism. I don't see any approach that would function in a highly reliable manner, and unlikely any of them would be interoperable with any other vendor's IPsec.

#5 Updated by Seth Mos about 7 years ago

  • Estimated time set to 12.00 h

we currently already have rc.newipsecdns which does purging and reloading of tunnels. You can pass the function the old and new p1 or p2 and it will reload the IPsec policies for that. With the granular reloading it works a treat. I've been doing that on the 350 tunnel setup for over a year.

In discussion on IRC we think that adding showing all interfaces, and a drop down next to it for the tier and a drop down for the vips on that interface to bind on.

The current dyndns code does not allow for updating a hostname on different WANs. That's a open ticket as well. We could arguably tie the dyndns code/functions into a rc.newipsecendpoint script that handles both racoon and the hostname that the endpoints would rely upon. That would make sure that the hostname the remote systems refer to and the local endpoints switch atomic.

My best guesstimate would be about 12 hours. I have one single install with multiwan in the field where I could write this on. Although it shouldn't be too hard to set one up.

The box in the main office already refers to the dyndns hostname, so if that updates it will call it's copy of rc.newipsecdns and update the endpoint on it's side.

Fully automated IPsec failover in the neighborhood of 1-3 minutes for convergence.

#6 Updated by Seth Mos about 7 years ago

Needs hooks in gateway monitoring.

If a gateway is down we call pfCtl.

alarm default {
        command on "/usr/local/sbin/pfSctl -c 'filter reload'" 
        command off "/usr/local/sbin/pfSctl -c 'filter reload'" 
        combine 10s
}

We need to extend these to trigger reload of Dynamic DNS, IPsec and later possibly OpenVPN. I would suggest adding OpenVPN now, I'll code the config code for it a bit later.

As it stands now, we can only send 1 command, perhaps we could send comma seperated values?
filter,ddns,ipsec,openvpn ? something like that?

#7 Updated by Seth Mos about 7 years ago

  • Assignee set to Ermal Luçi

#8 Updated by Ermal Luçi about 7 years ago

  • Status changed from New to Feedback

This has been complete on check_reload/pfSctl side.

#9 Updated by Chris Buechler over 4 years ago

  • Status changed from Feedback to Resolved

#10 Updated by Chris Buechler almost 3 years ago

  • Target version deleted (Future)

Also available in: Atom PDF