Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

3 Answers 3

up vote 2 down vote accepted
+50

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

share|improve this answer
    
Nice! "if you enable outside dynamic NAT or PAT, then all outside traffic must match a NAT rule when it accesses an inside interface." And yeah.. definitely working on getting rid of nat-control; but it's basically acting as a second ACL right now. Not fun. Gotta work on that 8.3 upgrade project! –  Shane Madden May 6 '11 at 5:13

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.

share|improve this answer
    
Yes, the Public interface has the lowest security setting. Dynamic NAT can be used for low -> high when the outside statement is added to the command. The NAT that triggered the issue worked great, just at the cost of triggering failures on all of the other NATs. –  Shane Madden May 5 '11 at 13:55

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?

share|improve this answer
    
Unfortunately, that is not the case. The ISP links are handled/switched between by the upstream router, the Public interface on this is handling all the PAT addressing. Additionally, there are no ip verify reverse-path commands present on the device. I'll add links to the full packet-tracer results as well as the config that broke it -- the full config is upwards of 9000 lines, so I can't really anonymize all of that.. but let me know if you want to see any specific parts. –  Shane Madden May 4 '11 at 1:45
    
RPF occurs after the xlate. A couple of thoughts: "When using dynamic PAT, for the duration of the translation a remote host can initiate a connection to the translated host if an access list allows it. Because the address (both real and mapped) is unpredictable, a connection to the host is unlikely. However, in this case you can rely on the security of the access list." (cisco.com/en/US/docs/security/asa/asa82/configuration/guide/…) Could you show the output of the "show xlate" command for the Voice & Inside interfaces? –  Chris Dix May 4 '11 at 3:32
    
More likely, the Public network 172.16.14.0/29 is overlapping another NAT rule. –  Chris Dix May 4 '11 at 3:57
    
I'm trying to get a maintenance window set up to break it again; I'll be sure to grab the translation list while it's broken - which leads in the same direction as a potentially overlapping NAT (re-checked, cannot find anything bigger than a /24 on the 172.16/12 range). But, the remote access VPN that the 172.16.14.0/29 network was set up for was working with no issues while the rest of the translations on Public (not touching those ranges, or the Voice interface) were broken. The config worked as intended, just had some major unintended consequences. –  Shane Madden May 4 '11 at 4:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.