Feature #1965
closed
Support Multiple IPsec Peers
Added by Jim Pingle over 12 years ago.
Updated almost 8 years ago.
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.
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?
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.
- 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.
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?
- Assignee set to Ermal Luçi
- Status changed from New to Feedback
This has been complete on check_reload/pfSctl side.
- Status changed from Feedback to Resolved
- Target version deleted (
Future)
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by Ermal Luçi