Cisco ASA 9.4 Default routing (with route map/nat)

[IP Team]

Hi All, 

I was wondering if someone could help explain the behaviour of the ASA 5545-X in relation to using a default route after a route-map/NAT has been applied. 

The route-map is applied on an internal-interface and attempts to forward traffic that matches an ACL to interface 'outside2':

- a route-map statement which matches a source/destination via an ACL.

- It sets a next hop IP which is the gateway on another interface (let's say outside2) that is within that gateways interface subnet.

The default route is applied via a static route as follows on the 'outside' interface:

- route outside 0.0.0.0 0.0.0.0 x.x.x.x 1

Object nat is applied (or PAT using the interface IP):

object network internal-interface-server-to-nat

nat (internal-interface, outside2) static interface

With the above config we got the following error message:

"routing failed to locate next hop for UDP from internal-interface:x.x.x.x/xxxxx to outside2:x.x.x.x/xxxxx"

We took out the route-map and created static routes with the destination trying to be reached with the same gateway used in the route-map. This worked alright.

What I wanted to find out was what that error log actually meant - there was already a default gateway, but it was on a different interface which the route-map pushed the traffic to. Is it because it's violated some sort of a check or routing table takes precedence over the route-map and they were in conflict?

Any detailed answer as to how the ASA would behave in this context would be greatly appreciated!

Thanks

[Rahul Govindan · Accepted solution]

Did you have an existing connection or xlate for this traffic via outside interface? If so, you may be hitting the bug CSCuv00272, which fails to use PBR for egress interface route lookup if there is a an existing conn or xlate.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuv00272/?referring_site=bugquickviewclick

Try clearing the nat/connection rules for that traffic before applying the PBR and see if it works.

Also try running a packet-tracer for a new flow to see the steps that the ASA would take for the traffic:

packet-tracer input inside udp x.x.x.x 12345 y.y.y.y 12345 detailed

[IP Team]

Hi Rahul, 

Thanks very much for your response. 

From what I remember the output from packet tracer still allowed it through. Having said that I think there was an existing connection for this flow through another interface. So we may well have been caught by the bug that you mentioned. 

Unfortunately I can't test clearing the connection because the service is now live, but I will keep this in mind before applying PBR!

Many thanks!