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

PIX Nat Logic not Logical.

Hi,

Can someone explain why I need security levels on a PIX - they seem VERY limiting. Or prehaps I don't understand the logic.

Example.

Interface E 0 - Internet

Interface E 1 - DMZ 1

Interface E 2 - DMZ 2

Interface E 3 - DMZ 3

Interface E 4 - Common DMZ

All DMZ's need to access the Internet. A PIX requires that an interface has a security level. The security level can't be the same on two interfaces.

The change in security levels means that the PIX will NAT the address regardless. Problem is I don't want it to NAT on any of the DMZ interfaces. Only to NAT when connecting to the Internet.

This doesn't seem possible - is it?

Thanks

5 REPLIES
Silver

Re: PIX Nat Logic not Logical.

Hi, I would first like to state that having the same securitylevel at your DMZ interfaces is possible. Only thing is that Cisco does not recommend it and so it is not supported by TAC. But if you need it, it can be used without any problem.

Default behaviour betweeen two interfaces with the same securitylevel is that no traffic is allowed in neither direction. So, in that case you would have to set static commands between these interfaces for the correct translation (allthough no translation is required, the correct static statements are required to get the correct entries at your xlate table)

Also you will need to configure all permitted traffic then. So, having the same securitylevel could get very complex.

If there is no need to have connections between the DMZ interfaces then having the same securitylevel is the best way for your config. But if connections between the DMZ interfaces are needed you can save a lot of time if you use different securitylevels.

Then how to configure connections to be not translated when they travel from DMZ to DMZ, while both DMZ's are translated to the outside interface address when connections to outside are made.

Let say you have 192.168.1.0/24 on DMZ1 and 192.168.2.0/24 on DMZ2, then you would need something like this (note that comments are preceded with a #)

nat (DMZ1) 0 access-list dmz1_nonat

nat (DMZ2) 0 access-list dmz2_nonat

#the nat 0 command is used to tell the PIX

#that no translation has to occure

#this nat 0 command is bound to an access-list

#permitting rules at this access-list are bypassed

#from translation

nat (DMZ1) 1 192.168.1.0 255.255.255.0

nat (DMZ2) 1 192.168.2.0 255.255.255.0

access-list dmz1_nonat permit ip 192.168.1.0

255.255.255.0 192.168.2.0 255.255.255.0

access-list dmz1_nonat deny ip any any

access-list dmz2_nonat permit 192.168.2.0

255.255.255.0 192.168.1.0 255.255.255.0

access-list dmz2_nonat deny ip any any

This is just an example ofcourse, but I hope you get the picture. If not feel free to ask further on.

Kind Regards,

Leo

New Member

Re: PIX Nat Logic not Logical.

Hi,

from my understanding: PIX OS will always do NAT.

But you can define to which addresses source addresses will be translated. This is useful for doing "dummy" NAT:

nameif ethernet1 inside security100

nameif ethernet2 DMZ security50

ip address inside 10.30.1.0 255.255.255.0

ip address DMZ 10.30.13.1 255.255.255.0

By using

static (inside,DMZ) 10.30.1.0 10.30.1.0 netmask 255.255.255.0 0 0

the PIX will leave the source address of the packets untouched (IMHO it will do NAT, but the translated source address is equal to the real source address).

This will work in both directions (10.30.1.0 -> 10.30.13.0 and 10.30.13.0 -> 10.30.1.0); you do not need to have "nat 0" or "nat 0 access-list" for the packets initiated from the DMZ going to "inside"

More networks which exists behind your inside interface can be defined in other static statements.

The example will only work for packets flowing between both networks; you can extend this for other DMZ interfaces/networks by using additional static statements (static (inside,DMZ2)).

After that you define your normal statics for Internet Access, for instance

static (DMZ3,outside) netmask 255.255.255.255 0 0

to translate 1 DMZ host statically.

HTH,

Christian

Silver

Re: PIX Nat Logic not Logical.

In reply to Christian:

What you state is correct, it also can be done with static commands, but this does not always work correctly when using two interfaces with the same securitylevel.

Also there is one big difference between using nat 0 and using static commands. If you are using static commands the PIX will proxy-ARP for the networks/hosts for which a static is in place, and if you use nat 0 then the PIX will not proxy-ARP. So, this is quite a big difference. IMHO it is better to use nat 0 command with access-list because of this difference.

Kind Regards,

Leo

New Member

Re: PIX Nat Logic not Logical.

The only problem I have encountered with using NAT 0 is that you need to build statics for all traffic that originates outside the firewall - if there is no existing NAT table entry, and even if the access-list allows it, the PIX will not build a NAT entry from a lower security level interface.

Just something to watch out for.

Silver

Re: PIX Nat Logic not Logical.

In reply to mplant:

You are right, but this discussion started with a question about prevending nat when dmz interfaces were communicating between eachother, while having same securitylevels on these dmz interfaces.

Though, if no translations are needed at all, and there is no need for having the PIX to proxy-ARP on the outside interface (that is, if your dmz hosts public adresses are not within the same subnet as your outside interface address) then you could even use the nat 0 command on the outside interface.

Kind regards,

Leo

Leo

92
Views
10
Helpful
5
Replies
CreatePlease to create content