I've been dealing with pix for nearly 2 years and still considered myself a newbie at it.
Can somebody have a look at the configuration below and tell me whether this configuration will work?
Basically it's a totally private network, no nat, and access control by networks (until my customer finalize their security policy)
My previous,working pix configuration used static commands, acls but I believed the configuration below does not need any static command since I've applied acls on every pix interface and totally disable nat.
PIX Version 6.2(2)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz security80
nameif ethernet3 dev security60
nameif ethernet4 ras security40
nameif ethernet5 failover security20
ip address outside 10.3.0.2 255.255.255.0
ip address inside 10.0.1.1 255.255.255.0
ip address dmz 10.5.0.1 255.255.255.0
ip address dev 10.1.4.1 255.255.255.0
ip address ras 10.9.0.1 255.255.0.0
ip address failover 172.16.0.1 255.255.255.0
access-list no-nat-all permit ip any any
access-list outside-acl permit ip 10.0.0.0 255.0.0.0 10.5.0.0 255.255.255.0
access-list outside-acl permit ip 10.6.0.0 255.255.0.0 10.1.4.0 255.255.255.0
access-list outside-acl deny ip 10.0.0.0 255.0.0.0 10.1.4.0 255.255.255.0
access-list outside-acl permit ip any 10.1.4.0 255.255.255.0
access-list inside-acl permit ip 10.0.1.0 255.255.255.0 10.5.0.0 255.255.255.0
access-list inside-acl permit ip 10.0.1.0 255.255.255.0 10.1.4.0 255.255.255.0
access-list dev-acl permit ip 10.1.4.0 255.255.255.0 10.0.1.0 255.255.255.0
access-list dev-acl permit ip 10.1.4.0 255.255.255.0 10.5.0.0 255.255.255.0
access-list dev-acl permit ip 10.1.4.0 255.255.255.0 10.9.0.0 255.255.0.0
access-list dev-acl permit ip 10.1.4.0 255.255.255.0 10.6.0.0 255.255.255.0
access-list dev-acl permit icmp any any
access-list dev-acl deny ip 10.1.4.0 255.255.255.0 10.0.0.0 255.0.0.0
access-list dev-acl permit ip any any
access-list dmz-acl deny ip 10.5.0.0 255.255.255.0 10.6.0.0 255.255.255.0
access-list dmz-acl deny ip 10.5.0.0 255.255.255.0 10.9.0.0 255.255.255.0
access-list dmz-acl permit ip 10.5.0.0 255.255.255.0 10.0.0.0 255.0.0.0
access-list dmz-acl deny ip any any
access-list ras-acl permit ip 10.9.0.0 255.255.0.0 10.1.4.0 255.255.255.0
nat (outside) 0 access-list no-nat-all
nat (inside) 0 access-list no-nat-all
nat (dmz) 0 access-list no-nat-all
nat (dev) 0 access-list no-nat-all
nat (ras) 0 access-list no-nat-all
access-group outside-acl in interface outside
access-group inside-acl in interface inside
access-group dmz-acl in interface dmz
access-group dev-acl in interface dev
access-group ras-acl in interface ras
route outside 0.0.0.0 0.0.0.0 10.3.0.254 1
Solved! Go to Solution.
I just verified my configuration in my pix test-lab (using port scanner & connecting socket software) and it's working fine indeed :)
I had no idea that could work that way - the 6.2 manual's entry for NAT still has the old chart for various scenarios - high to low use nat, low to high use static. I guess "identity address translation" is supposed to mean that nat 0 acl can now be used in place of a static. grrrrrrr. The 6.3 beta docs seem to be much clearer - nat 0 is in, static is for static port translations mainly.
Actually both replies are correct. "By the book" does require you to create statics. This is the recommended configuration.
NAT 0 will only work for this configuration IF the hosts on the higher interfaces have already initiated a session to lower interfaces to create an entry. If the host does not create an outbound session and/or is queit causing the translation to time out, the hosts on the lower interface will no longer be able to access them regardless of the ACL. This is the job of the static statement, to make those entries permanently available.
Is this new in 6.2(2)?
As far as I am aware you must still create static entries in order to be able to initiate connections from lower security interfaces.
For example I use the following static to allow traffic flow between an interface on a pix and and the inside IP. Of course, access lists are still required.
static (inside,vlan2) 126.96.36.199 188.8.131.52 netmask 255.255.255.0 0 0
This used to be a poorly documented issue on the PIX that caused me a whole host of problems around a year or so back. Has now this now been changed?
Nothing has changed and this behavior is correct although not really documented for obvious problems in implementation. It has always behaved like this as long as I have been working with the Pix since 5.1.1. The only thing [static] does is make a permanent entry in the translation table that will be known so that it can be seen by the lower security interface and referenced in an ACL.
The nat/global statements do this also, but it won't be permanent and may change if it's a global pool. When the translation timeouts, you will no longer be able access the inside hosts. That is, until the inside host initiates a session going out again.