While at a client this week, I ran across a fundamental change in post 8.3 cisco ASA routing logic which blindsided me for a while. The scenario was that after changing some VPN tunnel endpoints and hence changing subnet locations, we started seeing errors in syslog along the lines of

TCP session torn down, “no valid adjacency“

And the result being that the subnets were unreachable. The above error message lead me to investigate the routing on the cisco ASA, going through the static routes and routing table and so on. But those were correct. From past experience I knew that NAT had some role to play in routing but my impression was that a specific static routing entry would be given more importance than NAT. Some digging in the official ASA documentation shows this is actually not the case in post 8.3 firmwares:

Determining the Egress Interface In transparent mode, the ASA determines the egress interface for a NAT packet by using the NAT configuration; you must specify the source and destination interfaces as part of the NAT configuration. In routed mode, the ASA determines the egress interface for a NAT packet in the following way: If you specify an optional interface, then the ASA uses the NAT configuration to determine the egress interface. (8.3(1) through 8.4(1)) The only exception is for identity NAT, which always uses a route lookup, regardless of the NAT configuration. (8.4(2) and later) For identity NAT, the default behavior is to use the NAT configuration, but you have the option to always use a route lookup instead.

(8.3(1) through 8.4(1)) The only exception is for identity NAT, which always uses a route lookup, regardless of the NAT configuration. (8.4(2) and later) For identity NAT, the default behavior is to use the NAT configuration, but you have the option to always use a route lookup instead. If you do not specify a specific interface, then the ASA uses a route lookup to determine the egress interface.

Note the part in bold 🙂 That was the actual issue. Changing the NAT rule’s outgoing interface actually resolved my “no valid adjacency” problem. It pays to change your mindset away from normal cisco IOS when dealing with cisco ASA, to avoid falling into pitfalls like the above scenario.

As an endnote, what if you would like to override the above behavior? This is possible and it involves the use of the following option in ASDM which I only really appreciate after having discovered this:

The above option “lookup route table to locate egress interface” translates to the command line equivalent of “route-lookup”

Note however that the option is only available when the source and destination interface in the NAT rule are not set to “any”.

So, lesson learned… in the cisco ASA a NAT rule can override your routing table.