Showing results for 
Search instead for 
Did you mean: 


asa 5550 v8.25, asymmetric nat problem

Hi all. This is complicated, I'll try to explain succinctly.

I have an ASA that is one end of an IPSEC tunnel. The IPSEC tunnel dumps traffic off onto the ASA, but instead of forwarding to the next hop, we see a log entry like the following:

Mar  7 19:54:12 Mar  8 00:54:12 %ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows; Connection for tcp src outside: dst inside: denied due to NAT reverse path failure

When I run a packet trace, the trace stops on an RPF check:

Phase: 5

Type: NAT

Subtype: rpf-check

Result: DROP


nat (inside) 0


  match ip inside any outside any

    no translation group, implicit deny

    policy_hits = 3242

Additional Information:

Forward Flow based lookup yields rule:

out id=0x24305f50, priority=0, domain=nat-reverse, deny=false

hits=23428, user_data=0x24305ce0, cs_id=0x0, flags=0x0, protocol=0

src ip=, mask=, port=0

dst ip=, mask=, port=0, dscp=0x0

Normally I would look at where the trace stopped and figure out the problem from there, in this case, the 'nat (inside) 0' statement; only problem is that statement doesn't show up in the config. Here are my actual NAT statements:

nat (outside) 0 access-list nonat-outside-to-inside

nat (outside) 1 access-list nat-outside-to-inside

nat (inside) 0 access-list nonat-inside-to-outside

nat (inside) 1 access-list nat-inside-to-outside

nat (inside) 10 access-list nat-inside-to-client-priv

nat (inside) 15 access-list nat-inside-to-client-pub

nat (inside) 30 access-list nat-inside-to-inet

The access list 'nonat-outside-to-inside' has one relevant line concerning this specific traffic:

access-list nonat-outside-to-inside line 11 extended permit ip (hitcnt=0) 0xcba8a793

And access-list nonat-inside-to-outside has nothing that matches both the source and destination.

So, I don't actually have a statement that matches the error shown in the packet trace. I'm kind of stuck. From my reading of the rpf literature, I guess its an anti-spoofing feature, which leads me to believe that the firewall is sending the traffic back into itself instead of forwarding it on to the next hop, and the RPF check says, nope, you already tried to send that thru me, so I'm going to kill it. Which it should -- but why isn't it forwarding it out to the legitimate next hop? Its like the traffic is getting lost in the middle of the firewall, and I'm thinking -- BUG!

I'm kind of at a loss and considering opening a TAC case.

Does anybody have any ideas?


adding the following static resolved this particular error:

static (inside,outside) netmask

why the implementor neglected to include a static allowing access from outside to interfaces i'll leave y'all to think about!

Recognize Your Peers
Content for Community-Ad