Having some difficulties with a pix 6.3
facing the task to provide inbound onnections from lower security interfaces to several network segments behind the Pix's inside interface.
I'm not sure what my options are to provide translations for inbound connections without using static nat entries for every network.
Have read several posts overhere discussing the no nat-control feature, however as far as i know this is only applicable to Pix 7.
Also tried using "Nat 0 access-list #" configurations but seems this won't eliminate the need to provide specific static entries for inside networks.
Many Thanks for sharing your thoughts.
Solved! Go to Solution.
You should be able to provide inbound access to internal networks without using static commands if following set of commands are used-
access-list nonat permit ip any any
nat (inside) 0 access-list nonat
access-list 101 permit ip any any
access-group 101 in interface outside
These ACLs are currently opening IP access, so you may tighten this based on your requirements. Keep in mind that we are not translating internal networks to any different IP addresses, hence, outside hosts will use the real IP address of internal hosts to make inbound connections through PIX. Also, you will not see any translation entry in "show xlate" output.
Hope this helps.
Does this still apply if the connection is being made from the outside in ie the connection is initiated from the outside.
I can see how your commands above would allow internal clients not to be natted when they initiate connections out but not how the commands would allow connections to be initiated from outside to in.
Hmmz, than i made the wrong assumptions, cause i was asking myself the same question as Jon. I did use a nat 0 access-list configuration, but i've put it on the outside interface, like:
nat (outside) 0 access-list test
access-list test permit ip any any
So i'll try to configure it on the inside and will test again. I've Tightened security with access-lists on all interfaces, so security after translation/exemption has been taken care off.
Thanks so far
I've also found these explanations within the command reference:
The following example shows use of the nat 0 access-list command (NAT exemption) to permit internal host 10.1.1.15, which is accessible through the inside interface, to bypass NAT when connecting to outside host 10.2.1.3.
access-list no-nat permit ip host 10.1.1.15 host 10.2.1.3
nat (inside) 0 access-list no-nat
The following commands use NAT exemption on a PIX Firewall with three interfaces:
access-list all-ip-packet permit ip 0 0 0 0
nat (dmz) 0 access-list all-ip-packet
nat (inside) 0 access-list all-ip-packet
Would seem to me Jon has a point afterall. Let me test to verify things :-).
No i don't have a point and Vibhor is spot on. I have just tested this in our lab and using Vibhor's commands it works as he stated.
Many thanks Vibhor, i have been using Pix firewalls for a few years now and was not aware that this command was bi-directional. You live and learn !
Kindly Indicate for below scenario, Static necessary or not for Inbound Conncetion.
I am not able to access my Inside Server.
nameif ethernet0 outside security0
nameif ethernet1 inside security100
ip address outside 192.168.1.3 255.255.255.0
ip address inside 18.104.22.168 255.255.0.0
access-list no_nat_inside permit ip any any
access-list outside_acl permit icmp any any
access-list outside_acl permit ip 192.168.1.0 255.255.255.0 host 192.168.1.102
access-list inside_acl permit icmp any any
access-list inside_acl permit ip 22.214.171.124 255.255.0.0 192.168.1.0 255.255.255.0
nat (inside) 0 access-list no_nat_inside
static (inside,outside) 192.168.1.102 126.96.36.199 netmask 255.255.255.255 0 0
access-group outside_acl in interface outside
access-group inside_acl in interface inside