NAT Bypass, or NAT 0 on PIX and ASA firewalls can be confusing.
On unconfigured PIX and ASA traffic flows from higher security zones to lower security zone with no issues. Traffic will flow from inside to DMZ and outside as well as from DMZ to outside.
Once NAT is on:
# global (outside) 1 interface
# nat (inside) 1 10.0.1.0 255.255.255.0
dmz is not accessible from inside anymore.
This is happening because NAT (inside) statement tells the router to NAT all traffic coming from inside. Even if traffic doesn’t go to outside, PIX/ASA doesn’t realize it shouldn’t be NATted.
There are two options in this case (assuming DMZ is 172.16.1.0/24):
1. # global (dmz) 1 interface
2. # access-list INSIDE-NAT-BYPASS permit ip 10.0.1.0 255.255.255.0 172.16.1.0 255.255.255.0
# nat (inside) 0 access-list INSIDE-NAT-BYPASS
Option 1 means that traffic going from inside to DMZ will also be NATted. This may not be a good option as server in DMZ will see all traffic coming from one IP address – firewall’s DMZ interface.
Option 2 tells the router that traffic from inside to DMZ shouldn’t be NATted. It uses nat 0 statement which means “do not translate”.
It seems to be better option comparing to previous one. Furthermore, this is the regular way to exclude traffic from being NATtted. It’s also used when configuring VPN on ASA.
It may seem logical to put deny statement in ACL to exclude traffic from “nat (inside) 1” statement. It’s not supported, however by ASA therefore you’ll get error message:
# access-list INSIDE-NAT-TRAFFIC deny ip 10.0.1.0 255.255.255.0 172.16.1.0 255.255.255.0
# access-list INSIDE-NAT-TRAFFIC permit ip 10.0.1.0 255.255.255.0 any
# nat (inside) 1 access-list INSIDE-NAT-TRAFFIC
ERROR: Deny rules not supported in Policy Nat
At the same time if ACL referenced by “nat 0” statement has a deny statement it WILL BE NATtted. As “nat 0” means “do not translate.”, deny statement would be a double-negative, effectively telling the security appliance “don’t not translate” (or in other words, this packet should be translated).