Look no further than WatchGuard's Total Security Suite, providing defense in depth against today's most headlining attacks like Petya 2.0 and WannaCry. Keep your organization out of the news with protection from known and unknown threats.
COURSE of the MONTH
10 days, 16 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
Basic NO NAT setups and concepts on a PIX.
Posted on 2006-06-20
I'm going to use an example from a book that I'm having trouble understanding because if someone can explain this example to me, I think I'll have a grasp on what I need to know.
This is a PIX with three interfaces.
192.168.1.0/24 is attached to the outside interface.
192.168.5.0/24 is attached to the DMZ interface.
192.168.2-4.0/24 are all behind the inside interface.
The snippet of the configuration provided is this:
pixfirewall(config)# global (outside) 1 200.200.200.10-200.200.200
pixfirewall(config)# nat (inside) 1 0 0
pixfirewall(config)# nat (dmz) 1 0 0
pixfirewall(config)# static (dmz, outside) 200.200.200.1 192.168.5.5
pixfirewall(config)# static (dmz, outside) 200.200.200.2 192.168.5.6
pixfirewall(config)# static (inside, dmz) 192.168.5.0 192.168.5.0 netmask 255.255.255.0
pixfirewall(config)# access-list NO_NAT permit ip 192.168.2.0 255.255.255.0 192.168.5.0 255.255.255.0
pixfirewall(config)# access-list NO_NAT permit ip 192.168.3.0 255.255.255.0 192.168.5.0 255.255.255.0
pixfirewall(config)# access-list NO_NAT permit ip 192.168.4.0 255.255.255.0 192.168.5.0 255.255.255.0
pixfirewall(config)# nat (inside) 0 access-list NO_NAT
Now, I understand all of this config and most other configs, but for some reason I've just never gotten how no nat works exactly. I'd like to understand it well.
The book says "If a device from the inside interface tries to access a device on the dmz interface, it will not have its address translated -- this is based on the very last static command in the configuration." Fine and dandy. So, the static entry in question keeps things going from the inside -> dmz from being translated. What does the NO_NAT ACL do?
Originally, I thought it was some kind of similar thing, but in reverse. (i.e., telling things going out from the DMZ to not try and NAT to the addresses in question (the 192.168.2-4.0/24 networks), but that makes no sense because it's applied to the inside interface. Is that ACL applied with the "nat (inside)" statement just a redundancy of the static statement?
Also, what are the security implications of disabling NAT? Do the security level implications still apply (i.e., things from on the security100 inside can still reach things on the security50 DMZ interface but not vice-versa (assuming that there is no other ACL involvement), or does disabling NAT remove that difference in security level?
Someone please help me. I feel like I'm frustrated enough and asking such a hugely broad question that I'm going to go ahead and assign a high point value to hopefully make it worth someone's while.
Thanks very much.
This is a PIX with three interfaces.
192.168.1.0/24 is attached to the outside interface.
192.168.5.0/24 is attached to the DMZ interface.
192.168.2-4.0/24 are all behind the inside interface.
The snippet of the configuration provided is this:
pixfirewall(config)# global (outside) 1 200.200.200.10-200.200.200
pixfirewall(config)# nat (inside) 1 0 0
pixfirewall(config)# nat (dmz) 1 0 0
pixfirewall(config)# static (dmz, outside) 200.200.200.1 192.168.5.5
pixfirewall(config)# static (dmz, outside) 200.200.200.2 192.168.5.6
pixfirewall(config)# static (inside, dmz) 192.168.5.0 192.168.5.0 netmask 255.255.255.0
pixfirewall(config)# access-list NO_NAT permit ip 192.168.2.0 255.255.255.0 192.168.5.0 255.255.255.0
pixfirewall(config)# access-list NO_NAT permit ip 192.168.3.0 255.255.255.0 192.168.5.0 255.255.255.0
pixfirewall(config)# access-list NO_NAT permit ip 192.168.4.0 255.255.255.0 192.168.5.0 255.255.255.0
pixfirewall(config)# nat (inside) 0 access-list NO_NAT
Now, I understand all of this config and most other configs, but for some reason I've just never gotten how no nat works exactly. I'd like to understand it well.
The book says "If a device from the inside interface tries to access a device on the dmz interface, it will not have its address translated -- this is based on the very last static command in the configuration." Fine and dandy. So, the static entry in question keeps things going from the inside -> dmz from being translated. What does the NO_NAT ACL do?
Originally, I thought it was some kind of similar thing, but in reverse. (i.e., telling things going out from the DMZ to not try and NAT to the addresses in question (the 192.168.2-4.0/24 networks), but that makes no sense because it's applied to the inside interface. Is that ACL applied with the "nat (inside)" statement just a redundancy of the static statement?
Also, what are the security implications of disabling NAT? Do the security level implications still apply (i.e., things from on the security100 inside can still reach things on the security50 DMZ interface but not vice-versa (assuming that there is no other ACL involvement), or does disabling NAT remove that difference in security level?
Someone please help me. I feel like I'm frustrated enough and asking such a hugely broad question that I'm going to go ahead and assign a high point value to hopefully make it worth someone's while.
Thanks very much.
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
-
2
5 Comments
Basically in a nut shell .
When nat is applied when a packet travels from one interface out another it will appear that the source address is coming from the address which it is exiting on
Ie DMZ 192.168.1.1
inside 192.168.2.1
outside 192.168.3.1
If a packet travels from inside to out it will appear to be coming from 192.168.3.1
Now if yuo apply a no nat statment anything that is hit by this no nat acl will not be natted and its src address will be where the packet initiates from originally. This is mostly utilized in VPN tunnels to push a packet as interesting traffic across the tunnel.
Now the static translations..
based on the above static if a packet coming from a src of 192.168.5.0/24 attempts to hit a host in the DMZ the address is actually "translated" but in reality keeps the same address since the static translation is the same . But if a host say from 192.168.2.1 was to hit the DMZ it would appear to have come from 192.168.1.1 since it doesn't match the translation.
Did this make sense?
When nat is applied when a packet travels from one interface out another it will appear that the source address is coming from the address which it is exiting on
Ie DMZ 192.168.1.1
inside 192.168.2.1
outside 192.168.3.1
If a packet travels from inside to out it will appear to be coming from 192.168.3.1
Now if yuo apply a no nat statment anything that is hit by this no nat acl will not be natted and its src address will be where the packet initiates from originally. This is mostly utilized in VPN tunnels to push a packet as interesting traffic across the tunnel.
Now the static translations..
based on the above static if a packet coming from a src of 192.168.5.0/24 attempts to hit a host in the DMZ the address is actually "translated" but in reality keeps the same address since the static translation is the same . But if a host say from 192.168.2.1 was to hit the DMZ it would appear to have come from 192.168.1.1 since it doesn't match the translation.
Did this make sense?
I get that the NO_NAT access-list or generally using a "nat (interface) 0 <address>" command means that the "from" header in an applicable packet won't get rewritten as having come from an address in the global pool -- it just stays the same.
What is the use of the "pixfirewall(config)# static (inside, dmz) 192.168.5.0 192.168.5.0 netmask 255.255.255.0" in the example above?
What is the use of the "pixfirewall(config)# static (inside, dmz) 192.168.5.0 192.168.5.0 netmask 255.255.255.0" in the example above?
In that example its used to basically create a translation that keeps the from field the same because as packets traverse the interfaces they will undergo a translation.
So for example
lets use this
Exchange Server on LAN with an address of 192.168.5.245 connecting to a DMZ mail server with an address of 192.168.1.245
DMZ interface is 192.168.1.1
When the exchange server connects to the DMZ host the DMZ host will see the packet as coming from 5.245 due to the static translation.
But if a workstation say on anothe subnet was to connect to the DMZ host the mail server would see its ip as the DMZ interface ip address.
So for example
lets use this
Exchange Server on LAN with an address of 192.168.5.245 connecting to a DMZ mail server with an address of 192.168.1.245
DMZ interface is 192.168.1.1
When the exchange server connects to the DMZ host the DMZ host will see the packet as coming from 5.245 due to the static translation.
But if a workstation say on anothe subnet was to connect to the DMZ host the mail server would see its ip as the DMZ interface ip address.
Featured Post
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
The DROP (Spamhaus Don't Route Or Peer List) is a small list of IP address ranges that have been stolen or hijacked from their rightful owners. The DROP list is not a DNS based list. It is designed to be downloaded as a file, with primary intention…
This past year has been one of great growth and performance for OnPage. We have added many features and integrations to the product, making 2016 an awesome year. We see these steps forward as the basis for future growth.
Both in life and business – not all partnerships are created equal.
As the demand for cloud services increases, so do the number of self-proclaimed cloud partners. Asking the right questions up front in the partnership, will enable both parties …
Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:
• Key questions to ask when considering a partnership to accelerate your business into the cloud
• Pitfalls and mistakes other partners…
Suggested Courses
Course of the Month10 days, 16 hours left to enroll
770 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.