A side note. Once acl is set up to permit access to inside you will also
need to explicitly allow DMZ sourced traffic to outside. Notice how I used
explicit this time ;)
On Wednesday, July 11, 2012, marc edwards wrote:
> In your example higher to lower still applies as the inside interface
> still is using security level. You have successfully proven the stateful
> feature of the ASA. That is why we love them.
>
> What happens when you add an acl permitting say only telnet inbound on the
> inside interface? Will any other traffic pass besides telnet?
>
> That was what I am pointing to...
>
> Based on the original question. The ACLs need to be applied to the inbound
> interface of DMZ to permit traffic from DMZ to Inside.
>
> We are starting to overcomplicate this in efforts to see who is righter
>
> @ Brian, I love packet tracer :)
>
> Regards,
>
> Marc
>
> On Wed, Jul 11, 2012 at 2:33 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:
>
> Sadiq Yakasai @ 11/07/2012 18:17 -0300 dixit:
>
> Well, a simple test will confirm.
>
> Carlos, I dont know which it is but you either did not read my post well
> or did not understand it altogether. Whichever, read it once again and
> you will see that I said if there is an ACL on the interface where the
> traffic originates, yes, the traffic is subjected to the ACL rule.
>
>
> I did read your post as well as I can. Even after a reread, I still see
> that you mention "explicit deny" there, when it really does not matter if
> it is explicit or implicit. And in a previous post you mention that the
> security level could be used as a fall back of an ACL, which I think is not
> the case. ACLs either permit or deny, no way to "fail".
> (because "failing" would hit the implicit deny)
>
>
> Is there is no ACL on the interface the traffic originates from, and
> there is an ACL on the return path interface, then the firewall will not
> subject the traffic to the return path ACL.
>
>
> This is, in my view, making matters more confusing. The return traffic is
> never subject to any access control. Not ACLs nor sec level.
> The ASA does access control only on the initiating packet of a connection.
>
>
> This can be demostrated on the ASA below. I have configured a DENY ALL
> ACL on the outside (network interface) and I was able to initiate a
> telnet session from a device behind the ASA just fine. Why did the
> traffic allow this? Simply because of the security level rule of
> firewalling, which if I understand well is Sameer's first question.
>
>
> Agreed. In this example, there are no ACLs in the initial packet path,
> so the security level rule works. Also, keep in mind that ACLs can be
> applied inbound and outbound, so to be strict about the way something is
> configured, you have to make the direction of the ACL explicit.
>
> -Carlos
>
>
> Sadiq
>
> DC-ASA1(config)#
> DC-ASA1(config)# sh run int
> !
> interface GigabitEthernet0/0
> nameif network
> security-level 0
> ip address 10.241.1.68 255.255.255.248 standby 10.241.1.69
> pim dr-priority 120
> !
> interface GigabitEthernet0/1
> nameif datacenter
> security-level 100
> ip address 10.243.100.1 255.255.255.0 standby 10.243.100.2
> !
> DC-ASA1(config)# access-group DENY_ALL in in network
> DC-ASA1(config)#
> DC-ASA1(config)# sh run route
> route network 0.0.0.0 0.0.0.0 10.241.1.67 1
> DC-ASA1(config)# sh run access-group
> access-group DENY_ALL in interface network
> DC-ASA1(config)#
> DC-ASA1(config)# sh run policy-map
> !
> policy-map type inspect dns migrated_dns_map_1
> parameters
> message-length maximum client auto
> message-length maximum 512
> policy-map global_policy
> class inspection_default
> inspect dns migrated_dns_map_1
> inspect ftp
> inspect netbios
> inspect rsh
> inspect skinny
> inspect esmtp
> inspect sqlnet
> inspect sunrpc
> inspect tftp
> inspect sip
> inspect xdmcp
> class sxp-class
> set connection advanced-options tcp-state-bypass
> !
> DC-ASA1(config)#
> DC-ASA1(config-pmap-c)#
> DC-ASA1(config-pmap-c)# show conn
> 19 in use, 68 most used
> TCP network 10.241.1.67:23 <http://10.241.1.67:23> datacenter
> 10.243.100.5:5325 <http://10.243.100.5:5325>, idle 0:00:03, bytes 158,
>
> flags UIO
> DC-ASA1(config-pmap-c)#
> DC-ASA1(config-pmap-c)# sh run access-group
> access-group DENY_ALL in interface network
> DC-ASA1(config-pmap-c)#
> DC-ASA1(config-pmap-c)# sh run access-list
> access-list DENY_ALL extended deny ip any any
> DC-ASA1(config-pmap-c)#
> DC-ASA1(config-pmap-c)# logging on
> DC-ASA1(config)# %ASA-5-111008: User 'enable_15' executed the 'logging
> on' command.
> %ASA-5-111010: User 'enable_15', running 'CLI' from IP 0.0.0.0, executed
> 'logging on'
> %ASA-7-609001: Built local-host dat
Blogs and organic groups at http://www.ccie.net
Received on Wed Jul 11 2012 - 19:04:40 ART
This archive was generated by hypermail 2.2.0 : Wed Aug 01 2012 - 15:55:23 ART