Feature #6384
closed
Allow IPSEC P1 to have 2 peer remote gateway IP addresses to allow VPN failover faster without requiring DDNS
0%
Description
- IPSEC tunnel failover with DDNS takes over 2.5 minutes.
Today, with DDNDS and WAN gateway groups, failover from WAN to WAN2 at site 1, or a failure of WAN at site 2 requiring a site 1 WAN to site 2 WAN2 tunnel rebuild takes from 2.5 minutes to 3 minutes to failover because pfsense takes a little while to decide the WAN has failed (good, fine, we don't want flip flopping WANs..), then IPSEC takes a while to start to use the WAN2, then, Dynamic DNS takes a while to decide to update the DDNS entry to WAN2 IP, then the remote site must also agree on the new DDNS IP. My testing shows this to always exceed 2 minutes.
The Solution
SonicWALL (and others) allow Phase 1 to have TWO peer remote gateway IP addresses and then the peer identifier used can be still a FQDN or KeyID tag.
- This makes for a much faster tunnel failover than using DDNS.
- This reduced the overall complexity (no DDNS).
Updated by Cristian Mammoli over 7 years ago
I'll add my tests since I need this feature as well
strongSwan 5.5.0 which is used in pfSense 2.3 already supports multiple peers, or even subnets and ranges:
https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection#leftright-End-Parameters
Unfortunately this can't be configured in the gui.
If you hack the form validation checks in /usr/local/www/vpn_ipsec_phase1.php you can put whatever you want in the remote peer, such as 1.1.1.1,2.2.2.2 and it works as expected.
The remote peer is used in /var/etc/ipsec/filterdns-ipsec.hosts as well and the filterdns process exits with a syntax error if it is not a single ip or host.
Multiple peers should be "exploded" and put in that file one by one
Another thing that should be nice is not to check for duplicate peers in all the phase1s if the remote peer is "0.0.0.0" and we are configured as responder only. Or you should allow %any as a valid input for the peers which, as far as I know, is the same
Updated by Jim Pingle over 7 years ago
We are well aware that strongSwan supports it, but it's not that simple. There are other factors to consider such as automatic hostname resolution and static route management that would have to account for multiple addresses and which is in use.
Updated by Manfred Bongard over 5 years ago
Cloud is needed more and there is a reliable VPN connection very important. For this case a quick switch on failure is essential!
DynDNS is unuseless for a quick switch.
Updated by Jim Pingle over 5 years ago
With 2.4.4 you can use routed IPsec and a routing protocol like OSPF or BGP to accomplish failover. You can build an always-up tunnel to both peer addresses and let the routing protocol decide where to send the traffic. (Assuming both sides are pfSense or support routed IPsec...)
Updated by Manfred Bongard over 5 years ago
Your right. On our side we have our own IPs and BGP with FRR. But our Customers have only one IP from each ISP. Not in every environment our customer use a pfsense. If a customer use for example a fortigate he is able to use and accept two IPs but I am not.
From my side a gateway groupe is not nessesary (BGP via FRR). But I must be able to accept two IPs in phase one.