• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 570
  • Last Modified:

PIX: Static statement required for no NAT?

I have traditionally done two things to make the pix work without nat.  One is to set up a NAT 0 process.  And secondly I have put in a static statement to say that the addresses inside should be represented as themselves outside.  For example...

nat (inside) 0 10.0.0.0 255.0.0.0 0 0    

and...

static (inside,dmz) 10.0.0.0 10.0.0.0 netmask 255.255.0.0 0 0  

...this to define packets leaving inside for the dmz to retain their 10.* address as they egress the dmz port.  This combination seemed to solve a problem I had once with trying to have the packets reach the DMZ from inside.  But lately I found a fly in the ointment with this (has to do with multi-tiered pixen and non-natting - a long story for another day.)  My question is - is my static statement necessary?  Should the fact that I have a nat (inside) 0 process obviate the need to have such a static?  
0
mmedwid
Asked:
mmedwid
1 Solution
 
scraig84Commented:
Well - the answer is "it depends".  You are correct that the "nat (inside) 0" command will force no translation of the 10.0.0.0 network.  However, this is rare to do for a private address since this will force no translation across all interfaces.  It would be much more common to translate it to a public pool or PAT address on the outside and then use the static statement to force no translation into the DMZ.  However, you mention multiple firewalls, so it may be that you are not desiring any NAT on this firewall for that group of addresses.  If that is the case, you are correct that the static statement would be redundant.
0
 
lrmooreCommented:
I agree with Scraig84.
I typically use nat 0 with an access-list to define traffic for an IPSEC VPN tunnel.
You need to keep the static nat mapping because you are going from one security level to another, regardless of whether or not you use NAT. Static mappings take precidence over anything dynamic.

From the PIX command reference:
"Use the static and access-list commands when you are accessing an interface of a higher security level from an interface of a lower security level; for example, when accessing the inside from a perimeter or the outside interface."

0
 
ChriskohnCommented:
Dear mmedwid:
here is a link that may help clarify your question,
http://www.cisco.com/warp/public/707/28.html
I believe that you would need to keep both statements because as Irmoore points out, if you wish traffic to flow from both lower security level to higher and visa versa. This is complicated by the fact that you are using the same IP subnet within your DMZ and your Inside network (which isn't the usual case), you would still need to define the static command as you have it, otherwise depending upon how and where you apply your ACL's you may have difficulties with traffic flowing both ways. Hope this helps, Chriskohn
0
 
ChriskohnCommented:
Dear mmedwid:
here is a link that may help clarify your question,
http://www.cisco.com/warp/public/707/28.html
I believe that you would need to keep both statements because as Irmoore points out, if you wish traffic to flow from a lower security level to higher you would normally  use the static command. I would be concerned about bidirectional communication without the static statement. This scenario is complicated by the fact that you are using the same IP subnet within your DMZ and your Inside network (which isn't the usual case), you would still need to define the static command as you have it, otherwise depending upon how and where you apply your ACL's you may have difficulties with traffic flowing both ways. Hope this helps, Chriskohn
0
 
mmedwidAuthor Commented:
thanks Chris.
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now