Showing results for 
Search instead for 
Did you mean: 

VPN Failover on FTDs


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.

15 Replies 15

Marvin Rhoads
VIP Community Legend VIP Community Legend
VIP Community Legend

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.

Yeah from everything I read and thru my on labbing you can't do failover Site-to-Site VPNs on FTDs. Just wondering if anyone has ever done it.


Did you have to create two Remote Access policies in the FTD?

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. and 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.


Wait a minute. How are you binding the RA VPN policy to both interfaces and doing ip sla?

If you put both interfaces in the same zone I can see how you bound the ra vpn to both interfaces if you selected the outside zone.

Ip sla wont let you configure it if you have two interfaces in the same zone (tried it and the ftd barks at you).

So what type of Flexconfig are you using that you're not specifying in your answer?

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:


			<HostName><redacted> VPN</HostName>

As you can see in the site certificate, both and are SANs. So either one will work fine and not throw a certificate error to the end clients.

multisan certificate info.PNG

So you telling me what I originally suspected which is you can't do redundant VPNs on the FTD for site to site vpns and to do redundant ra vpns you need to do dynamic routing, have both interfaces in the outside zone, and have the cert with two DNs in it? If you don't do that it won't work correct?

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.

How are you NATs statements? Do you have double entries?

You make a single NAT entry in the FMC GUI (e.g., Inside-Outside). When it deploys it takes into account that two interfaces belong to outside zone and puts two entries in the running-config.

I can see that working for Internet but if you have any static NATs I can see you using double entries (one for ISP 1 and the other for ISP 2). I can tell you from experience that redundant site to site vpns will not work on the FTD because it binds the VPN to whatever interface you put it on so if you tell it to use the outside interface and Internet goes down it does which over to the backup interface in the FTD even if you create a second site to site vpn policy for the backup interface. In fact when you look at the routing table it will still say the VPN is attached to the outside interface and not the backup interface which means you have to rip out the site to site configs, deploy it to clear the FTDs, readd the site to site with the backup interface, and deploy it again. 100% non automatic failover.

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):

Under new features:

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers