ASA 8.3 nat-control issue

[lanli_ltp]

There is no explicit "nat-control" command in ASA 8.3. But what's the default behavior for NAT? If there is no NAT rule matching the incoming packet, does the packet get dropped, or simply passed through as is?

The 8.3 Migration document mentioned a strange way to migrate "nat-control" command using special object obj_0.0.0.0. It implies the packets that have no matching NAT rules are passed through as is. But I was told the packets are dropped if there is no matching NAT rule.

[Panos Kampanakis]

The default behavior in 8.3 for a packet that doesn't match a nat rule is to pass it untranslated (as with "no nat-control").

I hope it answers your question.

PK

[chandrareddy]

Is this the behavior that is actually observed on the ASA 8.3 device? Yes, the ASA 8.3 documentation says that you do not need NAT rules to allow the traffic through as is without translation.

I do not have access to an ASA 8.3 device to test the actual behavior but I did hear from one of our customers that when they moved to ASA 8.3, they had to add a whole bunch of Identity NAT rules to allow the traffic through. Our customer was also complaining that the in-place migration performed by the ASA 8.3 software does not add these Identity NAT rules automatically. When they contacted the Cisco support team, they did say that this is the expected behavior contrary to what the ASA 8.3 documentation says on this issue and they are going to keep this behavior in the near future.

So it would be helpful to see a packet trace from the ASA 8.3 device to confirm this behavior.

[mirober2]

Hi Chandrasekhara,

As mentioned above, the correct behavior is that any packet not matching a NAT rule will simply pass untranslated (i.e. no nat-control). Here is an example packet-tracer that shows this on an ASA that has no NAT commands configured:

ASA# packet-tracer in inside tcp 10.1.1.1 12345 192.168.0.1 80
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         dmz
Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 49053, packet dispatched to next module
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: dmz
output-status: up
output-line-status: up
Action: allow

That being said, you may need to setup identity NAT rules if the packet may match other configured NAT rules in either the forward or reverse directions since the ASA checks the NAT rules for both directions. For example, if you have a dynamic PAT setup to allow outbound Internet access for an entire subnet, you might need to setup identity NAT if you have certain hosts or flows that you don't want to be translated by this rule.

Hope that helps.

-Mike