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?
