Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
Community Member

disassemble a complex nat statement

hi all,


I have a PIX 7.0 with multiple complex nat statements that read something like this :

global (outside) 1 interface

global (dmza) 1 10.0.1.100

global (dmzb) 1 10.0.2.100

global (backup) 1 10.0.3.100

nat (inside) 1 192.168.1.0 255.255.255.0

nat (dmza) 1 10.0.1.200 255.255.255.255

nat (dmza) 1 10.0.1.201 255.255.255.255

nat (dmzb) 1 10.0.2.200 255.255.255.255

nat (dmzb) 1 10.0.2.128 255.255.255.128

nat (outside) 1 access-list outside_nat_acl

I´m not sure why everything was cramped in a single nat ID. Isn´t it more practical to use different NAT IDs for different use cases ?

Something like :

1 = inside to outside

2 = inside to dmza

3 = inside to dmzb

4 = inside to backup

11 = dmza to inside

12 = dmza to outside

21 = dmzb to inside

etc...

Of course the guy who wrote this ruleset left the building ^^.

Later,

Oliver

2 ACCEPTED SOLUTIONS

Accepted Solutions
Hall of Fame Super Blue

Re: disassemble a complex nat statement

keller.oliver wrote:

hi all,


I have a PIX 7.0 with multiple complex nat statements that read something like this :

global (outside) 1 interface

global (dmza) 1 10.0.1.100

global (dmzb) 1 10.0.2.100

global (backup) 1 10.0.3.100

nat (inside) 1 192.168.1.0 255.255.255.0

nat (dmza) 1 10.0.1.200 255.255.255.255

nat (dmza) 1 10.0.1.201 255.255.255.255

nat (dmzb) 1 10.0.2.200 255.255.255.255

nat (dmzb) 1 10.0.2.128 255.255.255.128

nat (outside) 1 access-list outside_nat_acl

I´m not sure why everything was cramped in a single nat ID. Isn´t it more practical to use different NAT IDs for different use cases ?

Something like :

1 = inside to outside

2 = inside to dmza

3 = inside to dmzb

4 = inside to backup

11 = dmza to inside

12 = dmza to outside

21 = dmzb to inside

etc...

Of course the guy who wrote this ruleset left the building ^^.

Later,

Oliver

Oliver

Actually the way it has been done saves a lot of extra config ie. you only need one "nat (inside) 1 192.168.1.0 255.255.255.0" statement and this works for all traffic from the inside to any other interface ie. outside, dmza, dmzb.

Besides i'm not sure it would work the other way because the inside traffic would always match the first nat so if you had

nat (inside) 1 192.168.1.0 255.255.255.0

global (outside) 1 interface

and

nat (inside) 2 192.168.1.0 255.255.255.0

global (dmza) 2 10.0.1.100

the traffic from 192.168.1.0/24 would always match the NAT with id 1 but there is no global with an id of 1 on the DMZ.

I don't have a pix handy to test but from memory the pix just searches through the NAT statements in id order so you have to do it the way he has.

However i could be misremembering

Jon

Cisco Employee

Re: disassemble a complex nat statement

What the person who left the building did is the right thing.

Now, you may think for management purpose it makes more sense to have different IDs for different interfaces but,

when you try to add the following:

nat (inside) 1 192.168.1.0 255.255.255.0

nat (inside) 2 192.168.1.0 255.255.255.0

You will get this error message "Duplicate NAT entry".

-KS

4 REPLIES
Hall of Fame Super Blue

Re: disassemble a complex nat statement

keller.oliver wrote:

hi all,


I have a PIX 7.0 with multiple complex nat statements that read something like this :

global (outside) 1 interface

global (dmza) 1 10.0.1.100

global (dmzb) 1 10.0.2.100

global (backup) 1 10.0.3.100

nat (inside) 1 192.168.1.0 255.255.255.0

nat (dmza) 1 10.0.1.200 255.255.255.255

nat (dmza) 1 10.0.1.201 255.255.255.255

nat (dmzb) 1 10.0.2.200 255.255.255.255

nat (dmzb) 1 10.0.2.128 255.255.255.128

nat (outside) 1 access-list outside_nat_acl

I´m not sure why everything was cramped in a single nat ID. Isn´t it more practical to use different NAT IDs for different use cases ?

Something like :

1 = inside to outside

2 = inside to dmza

3 = inside to dmzb

4 = inside to backup

11 = dmza to inside

12 = dmza to outside

21 = dmzb to inside

etc...

Of course the guy who wrote this ruleset left the building ^^.

Later,

Oliver

Oliver

Actually the way it has been done saves a lot of extra config ie. you only need one "nat (inside) 1 192.168.1.0 255.255.255.0" statement and this works for all traffic from the inside to any other interface ie. outside, dmza, dmzb.

Besides i'm not sure it would work the other way because the inside traffic would always match the first nat so if you had

nat (inside) 1 192.168.1.0 255.255.255.0

global (outside) 1 interface

and

nat (inside) 2 192.168.1.0 255.255.255.0

global (dmza) 2 10.0.1.100

the traffic from 192.168.1.0/24 would always match the NAT with id 1 but there is no global with an id of 1 on the DMZ.

I don't have a pix handy to test but from memory the pix just searches through the NAT statements in id order so you have to do it the way he has.

However i could be misremembering

Jon

Cisco Employee

Re: disassemble a complex nat statement

What the person who left the building did is the right thing.

Now, you may think for management purpose it makes more sense to have different IDs for different interfaces but,

when you try to add the following:

nat (inside) 1 192.168.1.0 255.255.255.0

nat (inside) 2 192.168.1.0 255.255.255.0

You will get this error message "Duplicate NAT entry".

-KS

Community Member

Re: disassemble a complex nat statement

Jon and KS,

thank you !

I see what the construction does, but what concerns me is : Using 5+ interfaces, 5 global pools and a lot of NAT statements, it seems to me that there are translations possible that are not intended.

Like (example slightly differs from 1st post) :

1. You want to nat inside to outside, dmza and dmzb

nat (inside) 1 192.168.1.0 255.255.255.0

global (outside) 1 interface

global (dmza) 1 10.0.1.100

global (dmzb) 1 10.0.2.100

2. Next, you want to nat dmza to outside and inside, but not dmzb

nat (dmza) 1 10.0.1.0 255.255.255.0

(global outside already exists)

global (inside) 1 interface

(global dmzb also exists)

Since there is a global (dmzb) statement from the first task, this would mean that there is natting that is not wanted.

I´m thinking of either incoming filter ACLs to deny unwanted traffic or using policy NAT, but first I have to make sure that there is no performance penalty for that.

Any source on performance for the different kinds of nat ?

Best wishes,

Oliver

Cisco Employee

Re: disassemble a complex nat statement

I see what you mean, ACL is the only way to block that.  Here is another thought.  If you just want to keep the IPs and not translate them to the interface IP then, you can do nat exemption with an acl and specify the destination.

Consider this:

nat (inside) 1 192.168.1.0 255.255.255.0

global (outside) 1 interface

nat (inside) 0 access-list nat0_acl

access-l nat0_acl permit ip 192.168.1.0 255.255.255.0 10.0.1.0 255.255.255.0

access-l nat0_acl permit ip 192.168.1.0 255.255.255.0 10.0.1.0 255.255.255.0 -----You can remove is this is not needed

Nat 0 with an acl is bi-directional meaning 10.0.1.0/24 can initiate traffic to 192.168.1.0/24

-KS

274
Views
0
Helpful
4
Replies
CreatePlease to create content