Showing results for 
Search instead for 
Did you mean: 

Separate VPN traffic to secondary ISP

Chess Norris
Level 4
Level 4


I have a customer that is getting a secondary ISP and he now wants to separate the traffic, so that VPN traffic continue going to the current ISP and all other Internet traffic to the new ISP. The customer will create an additional outside interface on the FTD for and use that as default gateway.

This is a policy based VPN tunnel between two FTD's and as long as the networks are specified in the crypto map, I shouldn't need a static route for the VPN networks that should be going through the tunnel. But do I need to put a static route for the other FTD’s public IP pointing to the current ISP router in order for the VPN peers to find each other?

The FMC is using this VPN tunnel to manage the firewall, so the customer is depending on that the tunnel is staying up. If the tunnel goes down we cannot revert the configuration.

Another option might be to configure the FTD on the other side of the tunnel with the other end's secondary interface as a backup peer, but I don’t know if that’s supported when using VPN tunnels between FTD's that are managed by the same FMC?



1 Accepted Solution

Accepted Solutions

@Chess Norris add the specific statics to the VPN peers and FMC, deploy those routes first. Once those statics have been deployed then change the default route via the secondary ISP and deploy again.

View solution in original post

10 Replies 10

@Chess Norris yes put a static route via the secondary ISP for the public IP address to establish the VPN tunnel. Otherwise it will use the default route via the primary ISP link.

The interesting traffic still needs to be routed out that different interface (secondary ISP link), otherwise it will go via the default route (which at present would be your existing interface). You could use reverse route injection (RRI) for the new VPN on the secondary link which will add the remote VPN networks to the local routing table or add static routes.

Thanks @Rob Ingram Worst case scenario we can always use the LINA config tool to revert the config, but hopefully it won’t be needed.

@Chess Norris leave your default route via the existing ISP link, as long as you connection to the FMC goes via that link you should be fine, then just create the more specific route via the secondary ISP link to the VPN peers etc.

@Rob Ingram Actually the existing ISP should handle the VPN traffic (including the FMC connection) and all the rest of Internet traffic should go to the new secondary ISP.

So if I put a default route to the secondary ISP and then a specific route to the current ISP router to reach interesting traffic + the VPN peer on the other side, that should be enough?

@Chess Norris add the specific statics to the VPN peers and FMC, deploy those routes first. Once those statics have been deployed then change the default route via the secondary ISP and deploy again.

@Rob Ingram That is a great idea to add the static routes first and deploy before adding the new default route.

adding new default without modify metric or delete the old one I think make FTD prefer first one add (old) and this not what you want 
think about that 


@MHM Cisco World Yes correct, I meant change the default route to the new ISP and not adding a new one.

We did the change yesterday and no issues at all, so thanks for all the advices.


You have one Outside interface you use for vpn and now you use it also for fmc.


Add two static route toward old ISP  (one for vpn and other for interest traffic)

Add new defualt route toward new ISP for any other traffic.

So instead shift traffic of vpn to new isp shit other traffic.

This way you dont need to change another important config for mgmt.


Thanks @MHM Cisco World. That's what I'm plannig to do.


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: