Pix: Permit Inside to access DMZ

I'm running a Pix 515 os ver 7.0

I'm having some trouble connecting to servers in the DMZ from the INSIDE interface unless I create an access list entry that explicitly permits it.

I only have two access lists.

ALLOWIN allows smtp and http access to our Exchange frontend and IIS servers located in the DMZ. It is applied to the outside interface on inbound traffic. I have the corresponding STATIC NAT which connects the DMZ to the OUTSIDE. This works fine.

DMZIN allows our Exchange frontend and IIS servers located in the DMZ to access our Exchange backend server as well as our DNS servers and Domain Controllers. It is applied to the DMZ interface on inbound traffic. This works fine.

However, the only way I can allow the machines in the DMZ to access the outside network is if I create a couple more lines in the DMZIN access list that explicitly permits this. This I don't have trouble believing in since I've been told that if an access list is applied to an interface (regardless of direction of traffic) it will deny all by default unless explicitly allowed.

This is the part I'm confused about. By default, since I didn't apply any access lists to the INSIDE interface, any host on the INSIDE network should be able to connect to any host on a lower security interface. This doesn't seem to be the case.

I cannot seem to connect to any server located on the DMZ from any host located on the INSIDE network, unless I explicitly allow it. And what's even more strange is that the corresponding access list entries that I use to allow INSIDE to DMZ connections are in the DMZIN access list. In other words, the DMZIN acl applied to the DMZ interface on IN traffic controls INSIDE to DMZ connections also!

Can someone explain to me why this works? I'm asking this because it defies my logical reasoning and in the case that It may be indicative of some deeper misconfiguration I would like to fix it.

Oh yeah.. and the security levels on my interface are OUTSIDE 0 DMZ 10 INSIDE 100


Reply to
Loading thread data ...

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.