Disabling nat-control on a "live" firewall

[pavlosd]

We have some old systems that use nat-control as they were upgraded from older pix releases.

My main question is, if we disable nat-control, what other actions are required?

For example, does the firewall needs to be restarted? or Clear all xlate and connection tables?

Reason I am asking is that we tried to test it but after the disabling nat control and removing static translations

no nat-control"

no static (inside,outside) 10.10.10.0 10.10.10.0 netmask 255.255.255.0

clear xlate local 10.10.10.0 netmask 255.255.255.0

but we still see messages

"No translation group found for udp src outside 192.168.0.1/58957 dst inside 10.10.10.10/514".

It is as partially working correct, with outbound initiated traffic working but inbound, complaining about no translation found.

I even allowed for xlate and conn timers to expire, but still same issue. In cisco documentation I couldn't find additional actions for this command.

[Jennifer Halim · Accepted solution]

If you disable "nat-control", you would need to make sure that you have no NAT statements at all, otherwise, it will reenable the "nat-control" feature, eventhough if you disable it.

If you check "sh run nat" output, you can't have any "nat" statement on the interface.

Disabling "nat-control" is normally used for internal firewall that protects different VLANs, and the firewall is not doing any NAT functionality at all. If your firewall is NATing traffic towards the Internet, disabling the "nat-control" will not make any difference.

You would still need to configure static 1:1 if traffic is initiated from outside towards inside as "no nat-control" purely handles the "nat" statements, not the static statements.

You would need to perform "clear xlate" to clear all the existing translations.

Here is a little bit more explaination on "nat-control" command:

http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/no.html#wp1753422

[pavlosd]

Great... Thanks for the answer. You are right.

The problem was caused by a nat statement, we had to "tune" it using access-list (nat x access-list name)  instead of a network command (nat x network subnet mask).