PIX Policy NAT: order of NAT commands

[ovt]

Hi!

Does anybody know in what order NAT commands (specifically _static policy NAT commands_) are evaluated?

For example, suppose we have IPSec VPN and want to translate all our local hosts ip addresses from 192.168.1.x into 192.168.3.x for traffic going via the tunnel. We need this because remote site also has 192.168.1.0 subnet. At the same time we want to allow connections from Internet to the internal host 192.168.1.4. This means that the same host 192.168.1.4 should be accessible via the tunnel and from Internet via two different addresses at the same time. The possible config is:

! Inside source translation for VPN traffic

static (inside,outside) 192.168.3.0 access-list vpn-nat

! Inside source translation for Internet traffic

static (inside,outside) 1.2.3.4 access-list server-nat

! We know remote overlapping subnet as 192.168.2.0

! They use static NAT too (192.168.1.x -> 192.168.2.x)

access-list vpn-nat permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0

access-list server-nat permit ip host 192.168.1.4 any

Note however that Policy NAT doesn't allow you to configure deny ACL entries. So, now we have two overlapped ACLs and statics for the same host 192.168.1.4 !

Surprisingly this config works!

NAT from inside:192.168.1.4 to outside(vpn-nat):192.168.3.4 flags s

NAT from inside:192.168.1.4 to outside(server-nat):1.2.3.4 flags s

I can initiate connections via VPN and then to Internet or vice versa - the result is always the same - it works.

The question is: how this can be? In what order static commands are evaluated? How the software can compare two ACLs and decide which one to use???

Also, could anybody translate the second part of the following excerpt from the PIX Command Reference from English into English:

"Because you cannot use the same local address in static NAT or static PAT commands, the order of static commands does not matter. Similarly, for static policy NAT, you cannot use the same local/destination address and port across multiple statements."

Regards,

Oleg Tipisov,

REDCENTER

[scoclayton]

Oleg,

First off, here is the NAT order of Operation as listed here - http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/cmdref/mr.htm#wp1032129

Order of NAT Commands Used to Match Local Addresses

The firewall matches local traffic to NAT commands in the following order:

1. nat 0 access-list (NAT exemption)—In order, until the first match. For example, you could have overlapping local/destination addresses in multiple nat commands, but only the first command is matched.

2. static (static NAT)—In order, until the first match. Because you cannot use the same local address in static NAT or static PAT commands, the order of static commands does not matter. Similarly, for static policy NAT, you cannot use the same local/destination address and port across multiple statements.

3. static {tcp | udp} (static PAT)—In order, until the first match. Because you cannot use the same local address in static NAT or static PAT commands, the order of static commands does not matter. Similarly, for static policy NAT, you cannot use the same local/destination address and port across multiple statements.

4. nat nat_id access-list (policy NAT)—In order, until the first match. For example, you could have overlapping local/destination ports and addresses in multiple nat commands, but only the first command is matched.

5. nat (regular NAT)—Best match. The order of the NAT commands does not matter. The nat statement that best matches the local traffic is used. For example, you can create a general statement to translate all addresses (0.0.0.0) on an interface. If you also create a statement to translate only 10.1.1.1, when 10.1.1.1 makes a connection, the specific statement for 10.1.1.1 is used because it matches the local traffic best.

Secondly, the statement is simply saying that you cannot use the same local address in multiple static NAT statements. For instance, the following is invalid:

static (inside, outside) 10.1.1.1 2.2.2.2

static (inside, outside) 10.1.1.1 3.3.3.3

The same principle holds tru for static policy NAT. Nothing overly earth shattering...

I agree that it is poorly worded and I will alert the doc team to take another crack at this for future revisions of the doc.

Does this help at all?

Scott

[ovt]

Thank you for the replay, but no, it doesn't help at all :(

Of course, I've read the documentation. Let's look at my example again step-by-step. We have two ACLs (vpn-nat and server-nat) that *do* overlap:

access-list vpn-nat permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0

access-list server-nat permit ip host 192.168.1.4 any

Both ACLs can potentially be used "to policy-NAT" the inside host 192.168.1.4 (the source of traffic). Correct?

More than that, if this host goes, say, to 192.168.2.99 both ACLs can be used "to policy-NAT" him. Correct?

This basically means that ACLs overlap. As they overlap "static-policy-NAT-commands" overlap too. Correct?

This clearly contradicts the documentation and your statement: "you cannot use the same local address in multiple static NAT statements", "The same principle holds tru for static policy NAT".

To put the truth, when I configured this and this worked I couldn't believe my eyes... It seems that PIX can choose between the too ACLs (and policy NAT commands) using something like longest-match algorithm (by destination mask). If this is the case, it's a very bad idea. The best approach here would be to allow "deny" entries in policy-NAT-ACL, so that the server-nat ACL look like this:

access-list server-nat deny ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0

access-list server-nat permit ip host 192.168.1.4 any

Why didn't developers do that?

Any comments are greatly appreciated.

[scoclayton]

Please note the following line from the docs and the information I posted:

"1) NAT commands with access-list option are searched, serially, in the configured order. The search stops on the first nat statement that matches."

Your original example listed the following:

! Inside source translation for VPN traffic

static (inside,outside) 192.168.3.0 access-list vpn-nat

! Inside source translation for Internet traffic

static (inside,outside) 1.2.3.4 access-list server-nat

! We know remote overlapping subnet as 192.168.2.0

! They use static NAT too (192.168.1.x -> 192.168.2.x)

access-list vpn-nat permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0

access-list server-nat permit ip host 192.168.1.4 any

In this case, the vpn-nat static is higher in the configuration. Therefore, if 192.168.1.4 sends a packet to 192.168.2.0, the vpn-nat static catches it. If 192.168.1.4 sends a packet to anywhere other than 192.168.2.0, the server-nat static catches it.

As for not allowing deny's in the policy NAT ACL's, this was a design decision based on performance implications. With this restriction, the access-lists can be concatenated and a single lookup can be done.

Hope this helps clarify matters.

Scott

[ovt]

Thank you for the clarifications of the documentation which is not very clear in this particular case. Next week I'll try to recreate the lab environment and test the order of NAT commands again.

Thanks again,

Oleg Tipisov,

REDCENTER,

Moscow