Recently ran into an issue where adding a dynamic NAT to an interface broke all translated traffic going through the interface with RPF failures. We found that the addition of the command caused NAT reverse path filtering to start dropping most traffic on the interface, previously RPF checking was not happening (or at least, was not previously showing up in packet-tracer
results).
The interface already had hundreds of NAT exemptions, statics, and dynamic policy NATs, but adding the first dynamic NAT (with a little /29 source restriction, and a destination interface unrelated to 99% of the translations that broke) triggered the failures.
Here's what broke it:
nat (Public) 33 172.16.14.0 255.255.255.248 outside tcp 0 0 udp 0
global (Voice) 33 10.0.8.180 netmask 255.255.255.255
The referenced rule in the RPF fails was the main PAT rule for the inside; nothing about the added config should have interfered with successful reverse of that rule:
Phase: 9
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
nat (public) 0 0.0.0.0 0.0.0.0 outside
nat-control
match ip Public any inside any
no translation group, implicit deny
policy_hits = 7274
Additional Information:
Full packet-tracer
results before NAT added: http://pastey.net/149630 and after: http://pastey.net/149631
So, the question is: is this really how NAT RPF behaves - only filtering for an interface once that interface has a dynamic NAT attached? Why did a dynamic NAT trigger it, but the dynamic policy NATs (behaving exactly the same, but with specified source and dest instead of just a source) did not? Or was it always happening, just with an implicit allow on the interface until there was a dynamic NAT, which then turned into an implicit deny if no rules matched?
5520 running 8.2.2, if it matters.
Looking at the first packet-tracer results it appears you have nat control enabled. If you add a dynamic nat to the outside interface while nat control is enabled then all traffic to the interface must match a nat statement. Cisco ASA 550 Series Configuration Guide -Configuring NAT Control
This is why you see a change of behavior once the dynamic nat is applied. NAT control is being applied to the outside and your existing NAT rules for the outside aren't appropriate for this situation. Hard to be more specific without seeing the config. The easiest solution is going to be disabling nat control (no nat-control).
Are you trying to NAT from a lower security interface to a higher one? If so, you need to do static NAT because, as far as I know, you can't use dynamic NAT in such cases.
If you have multiple WAN interfaces, NAT might be forwarding your packet out of the wrong interface and uRPF could be dropping them because of the incorrect address (Reference:Cisco). Do you have Cisco Express Forwarding enabled by any chance?