ERROR: ACE contains port, protocol, or deny. Removing NAT configuration

If you've ever seen the error message in the title above when configuring your Cisco ASA 55xx firewall the next few seconds may have been followed with clenched butt cheeks, lost TS sessions, a disconnected SSH session, no more web browsing, etc. Maybe not, depending on which interfaces your various traffic goes through. It's not like it ever happened to me. No. Never. Ok maybe once. Twice.

So here is a hypothetical scenario: You have a machine on your network that has been found to be infected with spyware, a rootkit, or is at least otherwise acting suspicious enough that you suspect it may be calling home to upload data or download additional nastyware. You want to block outbound traffic but you do not have an outbound access-list on the internet facing interface, so you get the idea of adding a NAT rule to prevent the private IP address of the host from being translated to a public IP effectively preventing it from going out to the internet. Brilliant! Problem solved!

So you log on to your Cisco 55xx firewall and add a statement to your NAT access-list which looks similar to:

access-list Allow-OutBound-NAT deny host any

... see the error message "ERROR: ACE contains port, protocol, or deny. Removing NAT configuration" and play out a scenario similar to the first sentence of this post.

So what happened? Well the NAT access-list is still there, but the statement which implements the access-list is gone. ie. a command further down in your config that might look like:

nat (1) access-list Allow-OutBound-NAT

Depending on your configuration that access-list might be responsible for allowing all traffic to NAT across the firewall to access internet resources or even different network segments. Because the firewall automatically removes the NAT statement all traffic relevant to that interface effectively stops. Oh. Crap.

The quickest way to fix the issue is to simply add the "nat (1) access-list Allow-OutBound-NAT" statement back in. Hopefully you were connected through an out of band session or through an interface that was not affected. Otherwise you grab a laptop and a rollover cable and haul ass to the datacenter to fix it. Don't bother trying to remove your borked command because it was never added. Just re-enter the relevant NAT command. You do have a copy of your config from before the change right?

Is this a bug? Most definitely. Obviously entering the access-list statement properly would have prevented this issue (you have to specify the IP protocol and you cannot  specify ports), but all the same this behavior should not happen.

The Cisco bug notice CSCsv32093 confirms this. The link is: (login required).

The issue was supposedly fixed in 8.0(5), 8.2(1), 8.2(4), 8.2(0.205), 7.2(4.26), 8.1(2.14), 8.0(4.24), 100.4(0.1)M, 100.3(0.2)M, 8.2(2.99) . Easy right?

Cisco rates this as a "minor" severity 4 issue, though it was considered a severity 1 when I allegedly ran into this problem! 3 minutes to figure out and fix the problem but it felt longer than that.

Suggestion? Well, you should be able to do this without worrying about your NAT access-list being removed, but if you are running an affected IOS version beware. Administer through out-of-band management and you might want to do this in a maintenance window. I know this should be a trivial operation, but the bug makes it otherwise. If possible have an outbound access-list on your internet-facing interfaces as well. We use outbound access-lists on many interfaces, but not on all of them. It's always a balance between what is technically possible and what the administration cost of implementing is, and sometimes just legacy/history which has not yet been changed.

Hope this helps you avoid this problem, or at least explains it if you've been bitten and don't understand why.


 [amazon asin=B002CBF1YU&template=iframe image&chan=default]

Website Security Test