asa 5550 v8.25, asymmetric nat problem

wilkess — Mon, 11 Mar 2019 22:39:25 GMT

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 20.31.87.54 Mar 8 00:54:12 %ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows; Connection for tcp src outside:172.28.253.1/8080 dst inside:10.20.161.33/8080 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

Config:

nat (inside) 0 0.0.0.0 0.0.0.0

nat-control

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=0.0.0.0, mask=0.0.0.0, port=0

dst ip=0.0.0.0, mask=0.0.0.0, 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 0.0.0.0 0.0.0.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 172.28.253.0 255.255.255.0 10.20.0.0 255.255.0.0 (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?

asa 5550 v8.25, asymmetric nat problem

wilkess — Thu, 08 Mar 2012 16:07:41 GMT

adding the following static resolved this particular error:

static (inside,outside) 10.20.0.0 10.20.0.0 netmask 255.255.0.0

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

topic asa 5550 v8.25, asymmetric nat problem in Network Security

asa 5550 v8.25, asymmetric nat problem

asa 5550 v8.25, asymmetric nat problem