Link to home
Avatar of rm250motox

asked on

ASA dual ISP routing issue

We have a 5510 configured with dual ISP's, one primary and one backup.  We are using tracked routes for failover which is working fine. We also have a 5505 that we use for our public network access both public wireless and 802.1x on our wired switches. We are using our backup ISP to supply internet access to the 5505. We use one of our backup ISP's static IP's for our 5510 backup interface and one for the outside interface on the 5505. Both of these public IP's use the same default gateway. The problem is that when we try to establish a VPN connection to the 5510 from our public network (Backup ISP,) we are not successful. Its seems that the packets are reaching the 5510 but aren't being returned. When I disable the backup interface on the 5510, everything works fine. Any insight into this issue would be greatly appreciated.

Avatar of Akinsd
Flag of United States of America image

Consider implementing HSRP, VRRP or GLBP redundancy

HSRP is Cisco proprietary protocol
VRRP is standard accross the board
GLBP lets you load balance but is only available on newer IOS (and routers)

GLBP is the best option if you have newer Cisco routers and your IOS supports it
Avatar of rm250motox


I would love to implement proper fail over and redundancy, unfortunately, we do not yet have a router in front of our ASA.
Most L3 switches support it too.
Are you saying the only solution to my problem is to not use the ASA for ISP failover?
You can setup a NAT pool and configure static NAT

GLBP just give you the ability to use both connections simultaneously (speed and bandwidth gain)
What would the static NAT look like?
Avatar of rauenpc
Flag of United States of America image

Blurred text
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
Static NAT is a form of port forwarding.

Check out the following links (forum and video)
I should've tried that in the first place. I imagine this only works because the device trying to establish a VPN is behind the same default gateway as the backup interface?

I suppose another possible reason for the issue isn't routing but rpf-check (reverse path forwarding check). Essentially a packet is dropped if it's received on an interface that shouldn't ever receive the packet. In your case the primary interface drops a packet that's sourced from the backup interface's subnet because it suggests a loop or an attack. I would have to run packet tracer to see the real reason... Routing or rpf.