Feature #1965
closed
Support Multiple IPsec Peers
0%
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.
Updated by Michele Di Maria over 12 years ago
It looks a duplicate of this:
http://redmine.pfsense.org/issues/1548
Actually this is explained better :D
Updated by Jim Pingle about 12 years ago
Another possible method...
Updated by Jim Pingle about 12 years ago
- 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?
Updated by Chris Buechler about 12 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.
Updated by Seth Mos almost 12 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.
Updated by Seth Mos almost 12 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?
Updated by Ermal Luçi almost 12 years ago
- Status changed from New to Feedback
This has been complete on check_reload/pfSctl side.
Updated by Chris Buechler over 9 years ago
- Status changed from Feedback to Resolved