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
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:
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.