From: Sushil Choudhary (suschoud@cisco.com)
Date: Wed Jun 25 2008 - 15:52:28 ART
The rules are tried in order.
1) nat 0 access-list (nat-exempt)
2) match against existing xlates
3) static
a) static nat with and without access-list (first match)
b) static pat with and without access-list (first match)
4) nat
a) nat <id> access-list (first match)
Note: nat 0 access-list is not part of this command.
b) nat <id> <address> <mask> (best match)
Note: When choosing a global address from multiple pools with
the same nat id, the following order is tried
i) if the id is 0, create an identity xlate.
ii) use the global pool for dynamic NAT
iii) use the global pool for dynamic PAT
5) Error
Regards,
Sushil Choudhary
#20683
----- Original Message -----
From: "Swap" <ccie77@gmail.com>
To: "'Tim'" <ccie2be@nyc.rr.com>; "'Naji Talj'" <ntalj@dcgroup.com>;
<security@groupstudy.com>
Cc: "'Cisco certification'" <ccielab@groupstudy.com>
Sent: Wednesday, June 25, 2008 10:50 AM
Subject: RE: PIX/ASA NAT
> On PIX and ASA,
>
> 1. For regular NAT (with out ACL), it's the best match
> 2. For NAT with ACL, it's the first match
> 3. For statics (NAT AND PAT) it's the first match
>
>
> On FWSM
> Point 1 and 2 are same, but Point 3 is different -
> 1. For regular NAT (with out ACL), it's the best match
> 2. For NAT with ACL, it's the first match
> 3. For statics (NAT AND PAT) it's the longest prefix match
>
>
> As per Cisco, local addresses in Statics can't be repeated. But in reality
> it can be, and the order is important. In case a Static PAT is added
> first,
> it will work even if the local addr is repeated
>
> e.g. This PAT will work
> stat (i,o) tcp 200.1.1.1 99 192.168.100.1 80
> stat (i,o) 200.1.1.1 192.168.100.1
>
>
> This PAT will not be allowed to be applied
> stat (i,o) 200.1.1.1 192.168.100.1
> stat (i,o) tcp 200.1.1.1 99 192.168.100.1 80
>
>
> HTH
>
>
> Swap
> #19804
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Tim
> Sent: Wednesday, June 25, 2008 5:33 PM
> To: 'Naji Talj'; security@groupstudy.com
> Cc: 'Cisco certification'
> Subject: RE: PIX/ASA NAT
>
> Hey Naji,
>
> Did you know there's another post that says the exact opposite !!!
>
> How sure are you?
>
> I figure the nat statements are processed more like a route table -
> longest
> match wins.
>
> But, a post yesterday, says it's really like how an ACL is processed.
>
> I don't know who is correct but I know you can't both be correct.
>
>
>
> -----Original Message-----
> From: Naji Talj [mailto:ntalj@dcgroup.com]
> Sent: Wednesday, June 25, 2008 8:13 AM
> To: Tim
> Subject: RE: PIX/ASA NAT
>
> Hi Tim,
>
> The sequence doesn't matter the most matching entry executes
>
> Rgds,
>
>
> Naji Talj
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Tim
> Sent: Tuesday, June 24, 2008 8:28 PM
> To: security@groupstudy.com
> Subject: PIX/ASA NAT
>
> Hi Guys,
>
>
>
> Does it matter in which order I enter nat commands?
>
>
>
> For example,
>
>
>
> nat (inside) 1 192.10.1.0 255.255.255.0
>
> nat (inside) 2 0 0
>
>
>
>
>
> (Assume I have the correct globals.)
>
>
>
> versus
>
>
>
> nat (inside) 1 0 0
>
> nat (inside) 2 192.10.1.0 255.255.255.0
>
>
>
> Given these config snippets, will the same thing happen for a packet
> with a
> source address of 192.10.1.x with either config?
>
>
>
> If so, is the reason because nat commands are evaluated like a route
> table
> ie most specific match takes precedence?
>
>
>
> Thanks, Tim
>
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 8.0.101 / Virus Database: 270.4.1/1517 - Release Date:
> 6/24/2008 8:41 PM
This archive was generated by hypermail 2.1.4 : Tue Jul 01 2008 - 06:23:23 ART