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

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

Understanding DMZ ACLs

I understand ACLs to work in this way on an ASA:

If the traffic DESTINATION is a host on the subnet where the ACL exists, it's considered INCOMING.  For example, if I want to allow my hosts on the inside to access the internet, since traffic sourced by my host destined for the outside is an outbound flow (high -> low zone) there is no need for an ACL.  However, the return is low -> high and does require an ACL.  Since the destination is a host on the inside, I create an INBOUND rule on the INSIDE interface.  Because the INSIDE interface is the highest security zone, the majority of the rules regarding the INSIDE interface are incoming.  We could write outgoing rules if we want to block zombies from sending spam, etc.  Now I'm putting in a DMZ, and I want my DMZ machine to access the DNS servers on the inside.  So I wrote a rule that says 'permit object-group TCPUDP object-group Internal_DNS_Servers eq domain'.  This is an incoming rule from the DMZ to the INSIDE interface permitting a flow from a lower zone (DMZ is 50) to a higher zone (INSIDE is 100).  This correlates with what I believe to be the appropriate usage of ACLs in that the DESTINATION is on the INSIDE interface, so I wrote the rule there to accept it.  I also understand that I need to write a similar rule on the DMZ interface to allow the outgoing request towards the INSIDE interface because INSIDE is a higer security zone.  Here's what I DON'T UNDERSTAND:

The firewall log says this:

4Feb 01 201213:29:55106023192.168.50.251276OSI-SUPPORT53Deny udp src DMZ-1: dst Inside:OSI-SUPPORT/53 by access-group "DMZ-1_access_in" [0x0, 0x0]

Why would I need a rule that is DMZ-1_access_in (incoming, so the destination should be the DMZ) yet have the source be the DMZ and the destination be INSIDE?  If the firewall is telling me that the ACL blocking the traffic is the inbound/incoming rule, I'd expect the source to be my DNS servers on the INSIDE and the destination to be the DMZ host.  Also, why would such a rule be necessary when the return traffic is coming from a higher zone to a lower one?  Maybe I'm thinking of this in separate steps like a request for information and a response, when really I need to be thinking flows?  In any case, I'm confused.


  • Firewalling
Everyone's tags (4)

Understanding DMZ ACLs

Hello Scott,

Lets first explaining the directions of an Access-group on an interface ( in,out)


On this scenario if a packet comming from the inside to the outside, if we want to restrict the traffic from the inside, we will need to apply the access list in witch direction?

Well we need to place ourselfs in the ASA inside interface, the packet will get IN the Inside interface and get OUT the outside interface. So we applied the access-group: in interface inside

Now lets do it from the outside to the inside, Again lets put ourselfs on the Outside interface of the ASA, we will need to open the interface to let the packets get IN from the outside to the inside, so again it would be. access-group in interface outside.

That being said, now lets talk about security levels and ACL's on the ASA.

From a Higher security level to a lower everything is allowed unless you want to restrict something.

From a lower security level to a higher you do need the ACL to allow the traffic.

On your case on the DMZ, you want to allow outbound traffic from the DMZ, okay so DMZ to inside.

So again put yourself into the ASA.

     -When a user tries to connect to a inside host, the 1st packet will be received on the DMZ interface and that packet needs to get IN into that interface so the direction would be IN instead of outbound.



Looking for some Networking Assistance? Contact me directly at I will fix your problem ASAP. Cheers, Julio Carvajal Segura