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