Cisco multi-gateway routing problem: ASA5505's and 1841's, MPLS, Tunnels

Refer to the attached diagram for a conceptual diagram of the network.

Sorry for the long post - trying to get as many details in as possible.

ASA's have a tunnel between them.  High speed cable network.
1841's connected in MPLS. 1.5mb T1's
All Internet-destined traffic must go out the MPLS routers (to 3rd party filtering host).  Only inter-branch traffic over the ASA-ASA tunnel can leave the ASA's.

ASA's have an SLA monitor on the outside, with failover to the 1841.
route outside <isp>  1 track 1
route inside 2

The 1841's are not in my control, and only route the internal LAN's.

The remote station ( gateway points to the remote ASA inside (

The Terminal Server ( has it's gateway set to the MPLS router, with static routes to specific remote IP's pointing to the ASA1 (route 1921.68.1.254), forcing traffic to the remote host over the ASA-ASA tunnel.

The problem is when the tunnel drops (e.g., either side loses connectivity to ISP).

The SLA is working, and the route outside is removed, leaving the default route set to the MPLS router.

However, the remote client cannot make an RDP connection to the server.  I can ping in both directions just fine.  

I believe the problem is described here (, basically, the ASA handles ICMP redirection, but non-ICMP packets are lost due to the path of the SYN packets.  

That is - the remote client initiates a 3389tcp connection to via (ASA2)
ASA2's SLA monitor has dropped the route outside, and sends the packet to 1841-2, over the MPLS, and pops out on 1841-1 to hit the Server.  
The Server, however, has a route to directed to ASA1, so the return packet gets sent to ASA1.
ASA1 drops the packet since it never saw the first packet from the remote host.

If I change the default gateway on Server to ASA1, then Internet traffic goes out the ASA, which violates the corporate policy.


How can I achieve failover on the ASA tunnel, and still maintain connectivity.
Who is Participating?
snowdog_2112Connect With a Mentor Author Commented:
Got this to work using the ASA as a single gateway.

Note: it requires Security+ license on the ASA.

This link describes it very nicely:

Here is the overview:
Create 2 outside interfaces.
Set route on each interface, with primary ISP having lower metric and a "track [n]"
configure "sla monitor [z]" to monitor an IP out the primary ISP.
configure "track [n]" for sla [z].

The sla will ping the IP you specify.  If the ping drops, the route for ISP 1 is removed, making the route for ISP 2 the de-facto default route.

When ISP 1 pings again, the route is added back with a lower metric than ISP 2, taking over the default.

I recommend something past the ISP gateway - I've found that pinging an ISP device physically in the location may not accurately identify a dropped link.  That is, if you're pinging the cable modem sitting next to the ASA, that won't tell you if the coax beyond the modem is down.
What is the device sitting behind the ASAs?

And, if I understand your question correctly, you want the ASA to turn around and establish the VPN Tunnel through its inside interface if its outside interface is not available; correct?
naderzConnect With a Mentor Commented:
One quick thought is to connect the 1841s on the outside of the ASAs and control routing within the ASA as you have above. For the tunnel, the ASAs will then be able to use the 1841 path if necessary.
Worried about phishing attacks?

90% of attacks start with a phish. It’s critical that IT admins and MSSPs have the right security in place to protect their end users from these phishing attacks. Check out our latest feature brief for tips and tricks to keep your employees off a hackers line!

I think the best choice would be to use a Layer3 switch as a gateway between clients and ASA/1841. You can then use dynamic routing to have the L3 switch determine which direction traffic needs to go. This way, traffic that can't go through the ASA never will and you won't have to deal with asynchronous traffic flows. This method is sometimes easier said than done.

Another method would be tcp state bypass. This is more of a bandaid than a good solution because the state bypass is set per interface and doesn't care about what routes are active so you would be bypassing state inspection at all times.
snowdog_2112Author Commented:
naderz - your suggestion is intruiging.

Is it possible (referring to the diagram) to build a tunnel sourced on the *INSIDE* interface?

Or am I combining the 2 suggestions above and moving the ASA *betwee* the LAN and the 1841 and simply treating it as a dual WAN configuration?!?!

Hmmm...the dual WAN may be the least CF'd solution.
naderzConnect With a Mentor Commented:
If I understand your objective correctly, the dual WAN solution would work. If you can place the 1841 after the ASA as an another "outside" interface, then you can have the following configs.

1. Create new network for connecting the ASA and 1841 on the outside of ASA. Let's say with security level 0 and your existing connection to isp can be security level 1.

2. Have your inside network point to the ASA as default gateway.

3. On the ASA have a default route pointing to the 1841. This will take care of your Internet connections, etc.

route outside2 "New IP address of 1841 on the network between ASA and 1841"

4. On the ASA have two static routes (similar to what you have now) as follows:
route outside1 <isp>  1 track 1
route outside2 "New IP address of 1841 on the network between ASA and 1841" 2

5. You will need to make sure that all appropriate VPN, ACLs, and NATs configs are in place between the outside and inside interfaces. It will take a little effort, but it's worth it.

I think I have covered all the steps. That should work allowing the ASA to track connections as they go in and out between your two sites.
snowdog_2112Author Commented:
I am putting together that plan today to see if there is something that will poke me in the eye.

I think the solution will work, but I'll have to test it at one location first (there are 8 total).

I will report back - probably not til later this week.  Thanks in advance!!!!!!!!
One thing to keep in mind is that if you put the 1841 behind the ASA you end up with a single point of failure. If the ASA blows a power supply or some other major failure, both connections to WAN and internet are inaccessible. Naderz solution does seem to allow for failover in the event that either WAN/internet connection fails or if the 1841 fails, but without redundant ASA's the firewall becomes a single point of failure.
snowdog_2112Author Commented:
I'm not looking to eliminate SPOF - the ASA and 2nd WAN was added for throughput, not redundancy.  We were running with SPOF on the 1841 until the ASA was added.

The ASA and cable link is admittedly less stable than the MPLS, but faster.  I am trying to provide for connectivity failover for the (all-too-often, it seems) cable ISP drops.

But I do agree with your sentiment, and it is duly noted.  Thanks!
snowdog_2112Author Commented:
still waiting for a window to test this...thanks.
snowdog_2112Author Commented:
Follow the link in my comment for an actual config example.

Works well - I drop one ping and the link switches, and the tunnel is up on the 2nd ISP.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.