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
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.
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.
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.
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.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in HA
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationCo...
I am currently unable to specify "crypto keyring" command when configuring VPN connection on my cisco 2901 router.
The following licenses have been activated on my router :