Ipsec failover
-
Recent snapshots remove the failover option and allow you to pick a CARP interface as the "WAN" interface. So now you can have multiple interface failover on IPSEC.
-
Recent snapshots remove the failover option and allow you to pick a CARP interface as the "WAN" interface. So now you can have multiple interface failover on IPSEC.
But can I specify and connect two tunnels with the same remote network on one pf box? Doesn't seem to want to work on the 2-18-2007 snapshot I'm running currently. Or can I do it if I use an OPTx interface for the second tunnel?
-andy
-
That's not possible currently. The failoveroption we are talking about here is meant to be used with CARP (machine failover).
-
So the IPsec failover doesn't fail over if the tunnel drops? CARP already syncs the ipsec stuff, does it fail over in the case of a machine failure? I'm confused then what it is for.
-
The old tab was for binding the ipsec service to the carp IP. This now can be done per tunnel when editing the tunnelsettings directly. It is for machine failover like I said, not for when a link drops (unless this causes a carp failover as well but it will stay on the same physical link but will run on another machine then).
-
Ok, better now, thanks :) Not sure what technical roadblocks there might be but is there any way planned or with a bounty to have tunnel failover?
-
The mainproblem will be to make the other end aware that the tunnel will come from another IP. This can be done when using mobile client mode I guess but then it would only work for failover on the on end and the link can only be established from the site with failover to the remote static end (which then can't use failover). Not sure if this can be done currently but adding a bounty to it might start investigating it further at least ;)
-
In this specific instance, there would be two endpoints with tunnels connected. If the primary fails then routing would need to go thru the secondary.
-
You can't establish the same IPSEC-Tunnel between the same subnets via seperate public IPs (this causes conflicts. It's not that easy like I said above. ;)
-
I mean on a totally different machine. Maybe I should be looking at a routing protocol instead of something in pf?
-
A solution using a manually triggered CARP failover with one LAN CARP IP acting as gateway for the local subnet and using mobile clients has been discussed somewhere else already. Search the forum.
-
I've thought about rigging something like this between two sites, each with two Internet lines and two pfSense boxes. The showstoppers for me were 1) Working out a script to failover the box if the Ipsec tunnel goes down. 2) Getting the remote end to failover to the second box when the first site fails over. I'm sure it would be possible given enough work, but I gave up on it…
My latest thought was creating a tunnel via WAN1, disabling it, creating a second tunnel via WAN2. This plan has the same unresolved issues as the two-box carp plan: automating the switch and getting the other end to follow suit. Cisco does have a failover tunnel (using dead peer detection or somesuch) option, but I have not seen this done between two multi-homed sites. I'm not any kind of IPsec expert or anything, but from my limited research this seems to be very hard to do without buying expensive proprietary equipment. -
Something like this could be done between sites that only run pfSense systems if some code was written for this kind of dead peer detection. Multiwan IPSEC is working with the latest changes in the snapshots, it just doesn'T detect failure or does failover.
