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