Has anyone gotten VPN failover to work on Cisco FTDs (not ASAs with backup peers)? Here's the scenario, we are trying to setup two FTD 2100s in a HA pair for failover of not only the Internet but for S2S and RA-VPNs as well. So far we can get the Internet failover to work but when it comes to VPNs the FTD won't switch over to the backup VPN setup. I noticed that even though the Internet did fall over to the backup circuit the VPN with still saying go out of the primary interface.
So I completely ripped out the VPN policy, deploy, recreate the VPN policy to use the backup interface, and redeployed to the FTD. Routing table now says route traffic destined for the remote lan using the VPN which is now tied to the backup interface. You would think traffic should work right?
Wrong. Traffic will not work (I configured NAT and the ACP to match the original VPN that was working on the primary interface). I do a packet tracer and it allows the traffic but when I ping from one machine to a machine in the remote office, no traffic.
Then I rebuilt everything back to the primary interface and no traffic on the VPN. So now even though I rebuilt everything I have no VPN whatsoever.
Has anyone got failover VPN to work on FTDs without manual intervention? I'm seconds away from telling my Director to stop selling these things and go to PA.
I have it working fine for remote access VPN at a couple of customers. BGP routing at one and static default with tracking for the backup at another. The SSL VPN certificate has a SAN for the FQDN of the addresses assigned to both primary and backup path outside addresses.
Neither customer has any site-site terminating on the FTD devices so I haven't had a chance to set those up yet.
It's a single RA VPN Policy. I've bound it to both outside interfaces. Routing only uses the second interface when the gateway for the first one is unreachable (
IP SLA monitor)(BGP learns the default route dynamically). The certificate has SANs for two FQDNs - e.g. vpn.company.com and vpn2.company.com. The VPN profile (xml file) has both the primary and alternate gateway specified.
So if the client tries to reach the primary FQDN specified in the profile and fails it automatically tries the second one. Since routing failover has kicked in and FTD is using the second interface's gateway as the default route, we get to that FQDN and associated address and find a valid certificate in return. Since the RA VPN SSL service is also bound to it, everything works seamlessly during failure of the primary link.
Sorry - I misremembered how I was doing the routing. I just checked it and I'm not using IP SLA on this one (that was a different Firepower installation).
In this RA VPN with automatic failover, routing to the Internet is via BGP. The two outside interfaces (both in the Outside zone and belonging to a single interface group) each have an BGP peer and whichever one is currently active (either works fine) is the default route for the FTD device.
Whether default via peer 1 or default via peer 2 is active, the RA VPN will work since in the VPN profile I have both the primary and backup set in the server list:
<ServerList> <HostEntry> <HostName><redacted> VPN</HostName> <HostAddress>vpn.<redacted>.org</HostAddress> <BackupServerList> <HostAddress>vpn1.<redacted>.org</HostAddress> </BackupServerList> </HostEntry> </ServerList> </AnyConnectProfile>
As you can see in the site certificate, both vpn.xxx and vpn1.xxx are SANs. So either one will work fine and not throw a certificate error to the end clients.
For site-site VPNs you can have backup interfaces and backup remote peers. I just haven't done that personally (yet).
The method I described for remote access VPN resiliency is the preferred one and what Cisco recommends. You may be able to do it with greater complexity using static routes and IP SLA but I haven't vetted that approach.
I know this post is old but some info here might be helpful to others:
Reply to donald.heslop1
The routing table issue you have is due to "Enable Reverse Route Injection" being enabled on the IPsec tab of the VPN connection. It's on by default, if you remove that, it will use route look-ups instead, resolving that specific issue.
Working L2L VPN failover (one side only failing over):
I currently have an FTD unit, remote site (with 2 ISPs, 2 peer IPs), connecting back to a hub ASA (multi-homed, so only 1 peer IP). I have a default route with an SLA for ISP 1 and a floating static to ISP 2. It fails over and back without issue.
Items to watch for:
Caveat: I have each ISP assigned to a different zone (outside/outside2). I couldn't get the SLA to floating static to work otherwise (tried numerous ways to keep it one zone and I'm pretty sure I checked with TAC too). Attached is a screenshot of the message you get if you try (I had semi-forgotten why I did this so I re-created it to double check).
-NoNAT needs to "Advanced -> Perform Route Lookup for Destination Interface" - Otherwise, it gets stuck going into the wrong zone (top down check)
-The VPN setup cannot have "IPsec -> Enable Reverse Route Injection" checked - Otherwise, you have the scenario donald.heslop1 mentioned.
-Required 2 Point to Point - Site to Site VPN entries. You cannot add the same node 2x in the hub to spoke or mesh configuration.
I'm in the process of working on a location that has two ISPs at both locations and trying to determine the best way to do this (how I found this). Will re-post once I'm sure of if/how to. I don't have the components to lab it... but my best idea right now is going to be like the above... but with 4 Point to Point VPN entries instead of 2 from the above reference.
FYI, my dual ISP at both ends failover worked. So I have Site A with 2 ISPs (active/passive failover) and Site B with 2 ISPs (active/passive failover) and using the scenario I described but with 4 entries in the FTD (A outside to B outside, A outside to B outside2, A outside 2 to B outside, and A outside2 to B outside2).
Backup peers officially supported in 6.6 (released today... so I've not tested and will probably wait at least a few months before doing this anywhere but a lab):
Backup peers for site-to-site VPN
You can now add a backup peer to a site-to-site VPN connection, for IKEv1 and IKEv2 point-to-point extranet and hub-and-spoke topologies. Previously, you could only configure backup peers for IKEv1 point-to-point topologies.
New/modified screens: Devices > VPN > Site to Site > add or edit a point to point or hub and spoke FTD VPN topology > add endpoint > IP Address field now supports comma-separated backup peers
Supported platforms: FTD