Understanding When A Cisco ASA NAT Rule Can Override The ASA Routing Table

Thanks to @bobmccouch who responded multiple times to my frustrated tweeting about Cisco ASA packet forwarding weirdness today. He pointed out some crucial forwarding behavior related to 8.3.1 and higher NAT, including some changes introduced as of 8.4.2. (Follow Bob. He tweets nerdy.)

So…here’s the thing. A Cisco ASA does not always determine the egress interface of a packet based on the routing table. Instead, it’s possible that a NAT rule is overriding the routing table. What Cisco says about this is as follows, taken from their official configuration documentation for the ASA:

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.
  • If you do not specify a specific interface, then the ASA uses a route lookup to determine the egress interface.

My scenario is a routed firewall, not transparent. So, to reword Cisco’s docs as I’m understanding them, if you’ve got a NAT rule that matches a particular packet, then the interface the translated packet will use to leave the firewall will be determined by your NAT rule destination interface (if you specified one), and NOT THE ROUTING TABLE. If you don’t like this behavior, you can use the “route-lookup” directive at the end of your NAT statement, or the comparable checkbox in ASDM “Lookup route table to locate egress interface”.

If you use identity NAT (translating a packet to itself, common with VPN firewalls), note that up through 8.4.1, the ASA would always do a route lookup to determine the egress interface. But as of 8.4.2 and higher, the ASA will not do a route lookup on identity NATs by default. Therefore, you might need to re-think your identity NAT ruleset to make sure that your NAT rules aren’t forwarding differently than what the routing table indicates, assuming that’s important to you. I’ve seen exactly this happen – traffic getting sent out the outside interface of a firewall due to a NAT rule, when intuitively the traffic should have been routing out the inside interface if the only thing weighing on the ASA’s forwarding decision was the routing table. This sort of behavior can drive someone mad until you realize that NAT has this ability to take precedence over routing depending on how the NAT rule was written.

Playing with this a bit on an ASA running 8.4.3, I found out that neither ASDM nor the CLI would let me put the “route-lookup” directive after the NAT statement unless both the source and destination interfaces were defined. If either source or destination interface were “any”, the “route-lookup” directive was simply not there.

nat (Inside,any) source static RFC1918 RFC1918 destination static Encrypt_McMurdo-Station Encrypt_McMurdo-Station ?

configure mode commands/options:
description Specify NAT rule description
inactive Disable a NAT rule
no-proxy-arp Disable proxy ARP on egress interface
service NAT service parameters
unidirectional Enable per-session NAT
<cr>

nat (any,Inside) source static RFC1918 RFC1918 destination static Encrypt_McMurdo-Station Encrypt_McMurdo-Station ?

configure mode commands/options:
description Specify NAT rule description
inactive Disable a NAT rule
no-proxy-arp Disable proxy ARP on egress interface
service NAT service parameters
unidirectional Enable per-session NAT
<cr>

nat (Inside,Internet) source static RFC1918 RFC1918 destination static Encrypt_McMurdo-Station Encrypt_McMurdo-Station ?

configure mode commands/options:
description Specify NAT rule description
inactive Disable a NAT rule
no-proxy-arp Disable proxy ARP on egress interface
route-lookup Perform route lookup for this rule
service NAT service parameters
unidirectional Enable per-session NAT
<cr>

I am more convinced than ever that it’s a mistake to think of the ASA as a router. The device simply does not follow the packet forwarding logic of Cisco IOS. If you need a device to perform VPN termination while truly acting like an IOS router, then the answer is…an IOS router. And if you object to using an IOS box for VPN tunnel termination because you love the HA functionality of Cisco ASA firewall pairs, allow me to point out that Cisco does offer stateful failover for IPSEC on IOS. You’ve got options.

Ethan Banks
Ethan Banks, CCIE #20655, has been managing networks for higher ed, government, financials and high tech since 1995. Ethan co-hosts the Packet Pushers Podcast, which has seen over 2M downloads and reaches over 10K listeners. With whatever time is left, Ethan writes for fun & profit, studies for certifications, and enjoys science fiction. @ecbanks
Ethan Banks
Ethan Banks
  • http://twitter.com/krunalshah Krunal Shah

    I was never able to find a good resource for packet processing thru ASA. Such things are being taught on JUNOS for security platform very well..

  • Ian Bowers

    I try to think of a firewall as a device that’s built for the purpose of breaking RFCs.   Since much of a firewall’s activities are not RFC compliant.   And I’ve always thought that learning what a firewall wants to do and not do by default is half the battle.  It’s like learning footwork in fencing…  that less interesting stuff you have to commit to memory before you can effectively swing a sword.  When I get “in the groove” during a firewall troubleshooting session, I’m in a completely different flavored trance than when I’m “in the groove” with a router.  if that makes any sense at all.  Additionally, the PIX was historically a NAT box before it was a firewall, so NAT has always seemed to have a more important role than one might expect.  That awful “nat-control” command for example, which has finally been deprecated.

  • Nick Kritsky

    Finally. We have always suspected that NAT processing happens before route processing in ASA and can override routing selection, but could not find the confirmation in Cisco docs. So it always was a bit of reverse engineering challenge between man and the machine.
    I wonder if Juniper’s Netscreen does the same. 
    That’s my word to all network engineer’s out there: “PIX OS is not IOS, ScreenOS is not JunOS”. The earlier you get it – the better :)

  • Mile Ljepojevic

    Hi,

    I just have one thing to add. When any of the interfaces is ANY, than route-lookup is performed by default and that is why you cannot add it on the end of your NAT statement.

    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.

    •If you do not specify a specific interface, then the ASA uses a route lookup to determine the egress interface.

    Have fun :)

    Mile Ljepojevic, BlueWater

  • mlan

    Thanks for posting this.  It has helped confirm the behavior we were seeing with identity NAT in 8.4.2.

  • Ateles

    I’ve been trying to lab this up and use packet tracer to see a scenario where this would happen. (It’s hard to break the thinking of the interfaces being for routing decisions and not packet matching – especially when ASDM makes it look like the match.) I’m not having any luck.

    Could someone outline a scenario for me where this would happen? Preferably with three interfaces – one input, one that the packet would normally be routed to, and one that the NAT will send it to.

    • mlan

      Below is what I ran into with three interfaces. I can’t speak to the original design decision for this config (no-nat across all interfaces), other than reference to a TAC SR which said to not use unspecified interfaces (“any”) in v8.4.2 NAT configs due to bug issues (really?). Please note the missing “route lookup” option for the identify NAT’s, which is what caused the problem in this example.
      object network obj-10.0.0.0
      subnet 10.0.0.0 255.0.0.0
      description Identity NAT catch-all
      nat (INSIDE,OUTSIDE) source static obj-10.0.0.0 obj-10.0.0.0
      nat (INSIDE,DMZ) source static obj-10.0.0.0 obj-10.0.0.0
      nat (DMZ,OUTSIDE) source static obj-10.0.0.0 obj-10.0.0.0
      etc.
      When a connection from the OUTSIDE was meant to be built to egress on the DMZ interface, it ended up matching the first rule, and the ASA built the connection incorrectly using the INSIDE interface as egress, even though the routing table had the correct information.

  • Pingback: ASA 8.4(3)+, NAT Behavior, and Remote Access VPN

  • Pingback: Cisco ASA Auto and Manual NAT discussion | Qwkhyena's blog…

  • Marc Abel

    Thank you for this, very helpful for me today.

  • Marc Abel

    Just an FYI – this behavior appears changed in 9.1. Neither I nor TAC was able to get NAT to override the default routing in 9.1.