I can make either tunnel preferred, however I was trying to only have a single tunnel active at a time. It looks like it won't be doable.
Main Topics
Browse All TopicsI'll start with what I'm trying to accomplish. I have two tunnels on a router connecting back to two separate routers at my central location across two separate internet ISPs via a DMVPN. Both tunnels connect and share dynamic routing information appropriately and work in every aspect they should.
I want one of those tunnels (Tun1) to be a backup for the other one (Tun0) so that Tun1 is only active in the event Tun0 goes down. I am currently using the Backup command to make Tun1 the backup interface for Tun0. The problem with tunnels is that they always show up even if they don't have connectivity to the other end. This means I just need to use Keepalive on the primary tunnel so it checks to see if it has connectivity to the destination IP. The problem I encounter is the destination IP address is NAT'd at my central location, so the Keepalive packet never makes it to the router terminating the VPN tunnel since the address in the Keepalive packet doesn't get translated. This means the tunnel is brought down until the Keepalive command is removed.
Does anyone know of a work-around for this issue or another way to go about building two tunnels where one is primary and the other is a backup?
Here is a simple diagram of where the devices live in reference to each other:
[Central VPN Router] --- [ASA Firewall] --- [Internet] --- [Remote Router w/two tunnels]
Here's the router config for Tun0 (Tun1 is practically the same without the backup commands):
interface Tunnel0
backup delay 0 120
backup interface Tunnel1
ip address 172.168.1.10 255.255.255.0
ip helper-address 192.168.1.100
ip mtu 1400
ip nhrp authentication password
ip nhrp map 192.168.100.1 700.700.700.700
ip nhrp map multicast 700.700.700.700
ip nhrp network-id 100
ip nhrp holdtime 300
ip nhrp nhs 192.168.100.1
ip tcp adjust-mss 1360
ip ospf authentication message-digest
ip ospf message-digest-key 10 md5 7 encryptedpw
ip ospf network broadcast
tunnel source FastEthernet8
tunnel destination 700.700.700.700
tunnel key 100
tunnel protection ipsec profile DMVPN
The 700.700.700.700 is the internet ip of our VPN router made available via a NAT'd internal address on our ASA.
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
It might be, but we will need to look at the configs for all devices. Normally if you are able to send/receive traffic through VPN, you should be able to do the same with ICMP traffic (keepalives). If it is being blocked somewhere, that would need to be fixed. The configuration you have posted so far looks good and doesn't look like it needs to be changed to fix the keepalives issue.
The problem is with the Keepalive packet itself in a NAT situation. My research has revealed that the target address does not get translated by NAT devices because the packet itself is encrypted due to the VPN tunnel.
Keepalive ends up bringing the tunnel down 100% of the time because it always goes to a non-existant address (the external one), and that is what I experience on my routers. The tunnel destination is the NAT'd address that the Keepalive packet uses (good for tunnel, bad for Keepalive), but Keepalive needs to be using the internal address of the device which it never knows.
The fundamental problem with what I'm doing is that NAT devices do not translate Keepalive packets because the packet is encrypted preventing the NAT device from inspecting the packet. I was hoping for a work-around or alternate solution that gets around this limitation of Keepalive/NAT.
Let me correct my last paragraph of the previous post...
The fundamental problem with what I'm doing is that Keepalive packets on a tunnel use the tunnel destination as their destination IP. If it was configurable, then I could just tell it to Keepalive against the internal IP address of the VPN device on the other end.
I keep having to fight off the thought that NAT can do anything here. The traffic is encrypted preventing a NAT device from doing anything with it. The real problem is a limitation of Keepalive or the assumption Cisco makes that it will always need to talk with the IP address of the tunnel destination.
It is not a limitation of Cisco, if you do want to use the Internal IP addresses, you can do that. Instead of using "tunnel protection ipsec profile " under the tunnel interface, configure crypto maps and apply them to Physical Interfaces to encrypt Tunnel traffic. This will allow you to use Internal IP addresses for Tunnel interfaces and keepalives will also use Internal IP Addresses.
Business Accounts
Answer for Membership
by: naveedbPosted on 2009-06-07 at 11:38:42ID: 24567570
If you are using dynamic routing, the correct method would be to configure routing in way that Tunnel-0 is preferred route for your traffic. When it goes down, the traffic would be switched over to Tunnel-1.