Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

no nat configuration without statics?

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

  • Other Security Subjects
1 ACCEPTED SOLUTION

Accepted Solutions
New Member

Re: no nat configuration without statics?

Hello,

This configuration looks perfectly alright. You can either use static or NAT 0 with access-list to access the higher interface. This is exactly what you're doing.

Rgds,

Desh

7 REPLIES
Silver

Re: no nat configuration without statics?

You will need static commands. Statics are necessary for accessing higher security interfaces from lower ones.

New Member

Re: no nat configuration without statics?

Hello,

This configuration looks perfectly alright. You can either use static or NAT 0 with access-list to access the higher interface. This is exactly what you're doing.

Rgds,

Desh

New Member

Re: no nat configuration without statics?

Thanks,

I just verified my configuration in my pix test-lab (using port scanner & connecting socket software) and it's working fine indeed :)

Silver

Re: no nat configuration without statics?

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.

Silver

Re: no nat configuration without statics?

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.

New Member

Re: no nat configuration without statics?

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) 172.50.0.0 172.50.0.0 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?

Silver

Re: no nat configuration without statics?

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.

99
Views
0
Helpful
7
Replies
This widget could not be displayed.