Showing results for 
Search instead for 
Did you mean: 

Multiple WAN SSH access on ASA5512X


Hopefully someone can explain this behaviour, its not what I'm expecting.

On our ASA5512 version 9.5(14), we have 3 ISPS, and 3 default routes, first a fibre link, second an ADSL, third a satellite link

route ISP1 1 track 1
route ISP2 10 track 2
route ISP3 20

These are the only routes.

We've configure access (ASDM,SSH) on each interface:

ssh ISP1

ssh ISP2

ssh ISP3

We can access via SSH on all three interfaces, despite, the primary default-route (and no other routes) still being in place.  I always understood we must have a static route out ISP2 and ISP3 to a management IP, otherwise traffic comes in ISP2 and out ISP1.  But it doesn't.  It just works, its almost as if the SSH and ASDM commands are a "route" command themselves (no next hop of course).  Its very strange how to explain it?

VIP Mentor

When you ssh into you ASA, a connection is build for that ssh-session. This connection can be seen  with "show conn all" like on this ASA where I connect from to both outside interfaces of the ASA:

ASA-HQ# sh conn all address
912 in use, 8501 most used
TCP outside1 NP Identity Ifc, idle 0:00:00, bytes 13683, flags UOB
TCP outside2 NP Identity Ifc, idle 0:00:28, bytes 3411, flags UOB

The connection is aware of the interface the session is terminated on and can reply back on the same interface.

Same will work for access to internal servers. In my ASA the active default-route points to outside1, but I still can reach my internal mailserver through outside2 with the corresponding NAT-entry.


Thanks for reply - I'm confused to the order of operations, I understand it knows what interface the connection was built on, but not how it knows to route the traffic - where does the route lookup happen?  In the routing table there is no route, this is what confuses me, how does it know to route the traffic to the next-hop?




Finding the interface is not only done through routing on the ASA. Also NAT can do this. The next-hop is then taken from a configured route. Although I'm not aware of any documentation of this behavior for traffic terminated on the ASA, I was told by a Cisco engineer that it's the same mechanism that handles this.