The truth about security-level

When you start studying Cisco ASA, the first thing that will interest you the most is the security-level of an interface. How traffic from a higher security-level interface is permitted to a lower security-level interface and how traffic from a lower security-level interface to a higher security-level interface is denied ‘by default’. This could be termed or referred as default access policies that are implicitly present on every interface on the ASA when configured with a security-level.

The truth is – in the real world you are never going to find an ASA that depends on these so called default access policies to filter traffic on the interface. The security-levels of the interface are not going to decide the fate of your network. Period. And I’ll tell you why…

Right out of the box, the security-level configured on an interface works just fine as it is intended to unless you configure an Access Control List on an interface. Once you apply an ACL on an interface, ASA does not consider the security-level of that interface while making permit/deny decisions, instead it checks the configured ACL on that interface for appropriate actions to be taken when there is a match. Any other traffic that doesn’t have a match is denied by the hidden implicit deny statement at the end of the ACL.

And here’s a hidden fact – Security-level does play an important role when making NAT Exemption decisions. More on this later…

Pinging ASA Interfaces

Being able to ping the ASA interface should seem like a normal behavior but there’s a little twist here. You cannot ping an interface other than the interface you are behind at. Got a little confused there, eh?

Let’s dig a bit deeper…

In the figure above, you will be able to ping the e1 interface of the ASA from the INSIDE network, e2 interface from the DMZ network and the e0 interface from the Internet. What you won’t be able to do is, ping e2 interface from the INSIDE network, e1 interface from the DMZ network, da da da daaa… you got that, right? And of course the pings are supposed to be originating from the hosts behind the interfaces and not the ASA itself.

This is no big deal but it can save you some troubleshooting time if you’re beating around the bush like me. :-P 

NAT Control (8.2 and below)

This is the first stepping stone when you start getting into the nitty-gritty details about NAT. Here is how an ASA exactly behaves when NAT control is enabled or disabled.

NAT Control is nothing but the function used to enforce the use of NAT in ASA. By default, this feature is turned off, so NAT is not required for transit traffic. But when it is turned on, NAT is enforced.

NAT control – disabled (The default)

  • No NAT required at all!
  • Except for outbound traffic destined to the ISP because they block RFC 1918 IP addresses and hence the packets will be dropped at the ISP’s end if you don’t translate it. But if you are using public IPs in your internal network then again NAT is not required.

      NAT control – enabled

  • NAT control requires that packet traversing the ASA in any direction match a NAT rule.
  • For same-security-traffic interface, NAT is not required if there isn’t any NAT rule applied on those interfaces. If there is a NAT rule applied say, an outbound NAT, then NAT becomes mandatory on that interface (this ones a little tricky).
Those of you who have migrated to 8.3 and above you need not worry about NAT-control! Although, here’s what you need to worry about;-)