Stupid implicit ACL Rule

Ok, so I'm trying to get my DMZ to talk to my clients. All my dmz traffic is getting dropped at the DMZ interface though.

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   172.16.111.0    255.255.255.252 Inside

Phase: 2
Type: ACCESS-LIST
Subtype: 
Result: DROP
Config:
Implicit Rule
Additional Information:

Result:
input-interface: DMZ
input-status: up
input-line-status: up
output-interface: Inside
output-status: up
output-line-status: up
Action: drop

Here's my ACLs:
Atl-ASA# sh run | grep access-g
access-group outside_access_in in interface Outside
access-group dmz in interface DMZ
access-group inside_access_in in interface Inside
access-group permit-all global

Atl-ASA# sh access-l inside_access_in
access-list inside_access_in; 1 elements; name hash: 0x433a1af1
access-list inside_access_in line 1 extended permit ip any any (hitcnt=0) 0xa925365e 

Atl-ASA# sh access-l dmz
access-list dmz; 1 elements; name hash: 0xa12380e4
access-list dmz line 1 extended permit ip any any (hitcnt=0) 0x2871029b

Atl-ASA# sh run int e0/1
!
interface Ethernet0/1
 nameif DMZ
 security-level 0
 ip address 172.16.110.1 255.255.255.0

Atl-ASA# sh run int e0/2
!
interface Ethernet0/2
 nameif Inside
 security-level 0
 ip address 172.16.111.2 255.255.255.252 

Atl-ASA# sh run | i same
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface

I know it's something extremely stupid, but I've looked at it for too long. I'm at the point where I need to put it down for a while and work on something else.

All help is greatly appreciated.

Comments

  • johnwest43johnwest43 Posts: 294Member
    have you tried a "clear xlates" after the acls were configed?
    can you post your nat/pat static and global config ?
    CCNP: ROUTE B][COLOR=#ff0000]x[/COLOR][/B , SWITCH B][COLOR=#ff0000]x[/COLOR][/B, TSHOOT [X ] Completed on 2/18/2014
  • jason_lundejason_lunde Posts: 567Member
    I may be mistaken but I think by default stuff has to be nattd on an ASA. you might have to turn off nat-control to get it to work. I am by no means a guru on these though....just work on them a bit.
  • burbankmarcburbankmarc Posts: 460Member
    Well I'm on 8.3.2 and the nat-control command is deprecated.

    Here's the only NAT config I have, which you can see it's inactive:
    
    nat (Inside,Outside) source dynamic Atlanta-Client NAT-Pool inactive
    
  • jason_lundejason_lunde Posts: 567Member
    Well, I happened to have a 5505 sitting here, so I upgraded it to 8.3.2, and applied your config. Mine worked fine. What are your nodes in the dmz/inside?...are they hosts, routers, or are you pinging from your ASA? Just make sure that your internal/dmz'd devices have the right gateways set, or appropriate routes in place.
  • AhriakinAhriakin SupremeNetworkOverlord Posts: 1,800Member ■■■■■■■■□□
    What hosts are you trying to talk to on the inside (can you post your packet-tracer command to match to the results). It strikes me that your inside subnet is pretty small, and usually when you have issues like this and packet-tracer is showing a vague ACL drop (as opposed to showing you the explicit ACL line) then it's being dropped for another non ACL but interface related reason in the ASP. E.g. you are trying to access the firewall's inside IP from another DMZ, it will never allow this.
    We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
  • burbankmarcburbankmarc Posts: 460Member
    Ok, I only have 1 linux server on the DMZ right now. What I'm packet tracing is my ASA DMZ interface to a router on my Inside interface.

    Here's a crude ASCII representation of this simple network:
    [2811]---172.16.111.0/30-------[ASA]---{Intertubes}
       |                            |
       |                            |
    [3560]                [Linux Server]
    

    And here's the packet-tracer:
    
    
    Atl-ASA# packet-tracer input DMZ icmp 172.16.110.1 1 1 172.16.111.1 det
    
    Phase: 1
    Type: ROUTE-LOOKUP
    Subtype: input
    Result: ALLOW
    Config:
    Additional Information:
    in   172.16.111.0    255.255.255.252 Inside
    
    Phase: 2
    Type: ACCESS-LIST
    Subtype: 
    Result: DROP
    Config:
    Implicit Rule
    Additional Information:
     Forward Flow based lookup yields rule:
     in  id=0xacc0a458, priority=500, domain=permit, deny=true
    	hits=10, user_data=0x6, cs_id=0x0, reverse, flags=0x0, protocol=0
    	src ip/id=172.16.110.1, mask=255.255.255.255, port=0
    	dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
    	input_ifc=DMZ, output_ifc=any
    
    Result:
    input-interface: DMZ
    input-status: up
    input-line-status: up
    output-interface: Inside
    output-status: up
    output-line-status: up
    Action: drop
    Drop-reason: (acl-drop) Flow is denied by configured rule
    


    Thanks for taking a look at this, I appreciate it.
  • burbankmarcburbankmarc Posts: 460Member
    Well I did something to get it to work, not sure what. Seems good though, thanks for looking into it all.
  • AhriakinAhriakin SupremeNetworkOverlord Posts: 1,800Member ■■■■■■■■□□
    What I'm packet tracing is my ASA DMZ interface to a router on my Inside interface..

    Like I said, there was your issue. The ASA never likes traffic to/from one of it's own interfaces to/from another DMZ. The control-plane is treated differently.
    We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
Sign In or Register to comment.