(6 votes, average: 4.33 out of 5)
Loading ...Traditionally, the PIX required a NAT translation for traffic flowing from one interface to another. Beginning with 7.0, this is no longer the case. The introduction of the nat-control command means that you can configure your PIX or ASA to allow traffic to flow across the security appliance without nat.
When nat-control is enabled NAT is required for all traffic flowing across the security appliance. When nat-control is disabled NAT is optional for traffic flowing across the security appliance.
What I learned the other day, though, is that even if NAT control is disabled, if you add a NAT configuration to an interface, all traffic originating on that interface must have a NAT rule in place. Here is the situation (simplified) from a recent forum discussion I was engaged in:
Nat-control was off. There were two high security interfaces named “inside” and “inside2″. The user wanted to PAT traffic from those high security interfaces out the outside interface, so he added two nat statements to his config.
nat (inside) 1 0.0.0.0 0.0.0.0
nat (inside2) 1 0.0.0.0 0.0.0.0
global (outside) 1 interface
This worked great for outbound traffic. Users on both interfaces could reach the Internet via PAT and all was well…except that the two interfaces could not talk to each other. When the user tried to send traffic from inside to inside2, he got the following translation error:
portmap translation creation failed for icmp src inside:192.168.200.1 dst inside2:192.168.0.150 (type 8, code 0)
As we now know, this error showed up because he did not have a NAT rule to cover traffic from inside to inside2 (or vice versa). He only had a NAT rule for the outbound PAT!
It appears that nat behaves on a per-interface basis, not a per-flow basis. My first thought was that traffic going outbound would use the PAT configuration, while traffic going from inside to inside2 would not need nat because of no nat-control. After labbing it up, though, I realized I was wrong.
So what was there to do? Since PAT is a requirement, the solution is more NAT. In this case statics were used to perform identity NAT for traffic flowing across the security appliance between the two inside interfaces:
static (inside,inside2) 192.168.200.0 192.168.200.0 netmask 255.255.255.0
static (inside2,inside) 192.168.0.0 192.168.0.0 netmask 255.255.255.0
Keep it in mind: Even with nat-control disabled, once you add a nat statement for PAT to an interface, you require NAT for all traffic on that interface. 
References:
nat-control in the command reference
The forum thread at tek-tips that prompted this post
I went through migrating a version 6 pix to version 7 then configuring it for no nat control. The biggest driver for disabling nat control was because we had hundreds of nonat access-list statements, which meant we could remove the bulk of this configuration with nat-control disabled. We have 5 interfaces on the PIX, all at different security levels. 2 of these interfaces (interface A & B) provide connectivity to the internet (through global PAT) – so this means we have to use Static Identity NAT entries for traffic moving from these interfaces to the other internal interfaces/networks partitioned by the pix.
Interface A – Internal and provides internet connectivity
Interface B – Internal and provides internet connectivity
Interface C – Internal, no internet.
Interface D – Inernal, no internet.
Interface E – External (public).
With this configuration – a network (X) on interface A sending traffic to a network (Y) on interface D is fine because there is a SNAT statment in place. The same network (X) under fault conditions could also send traffic through interface C (backup path) to the same destination network (Y) on inerface D. This is where connectivty breaks – the SNAT for network X (Interface A-D) appears to be interferring with return ICMP traffic (network Y to network X), other application traffic is fine – any ideas what is causing this. By removing the SNAT for network X (interface A-D), return ICMP traffic is fine.
So normally…
Network X (Int A) ——> Network Y (Int D) – fine
static (A,D) network X network X netmask 255.255.255.0
Under Fault conditions…
Network X (Int C) ——> Network Y (Int D) – return icmp fails unless the above SNAT statement is removed. All other application traffic ie: telnet,ssh works fine with the SNAT statement still in place.