01-19-2010 06:11 AM - edited 03-11-2019 09:58 AM
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
Solved! Go to Solution.
01-19-2010 08:37 AM
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
01-19-2010 11:51 AM
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
01-19-2010 08:37 AM
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
01-19-2010 11:51 AM
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
01-19-2010 11:30 PM
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
01-20-2010 05:02 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide