Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
Community Member

ASA ACL seems to be being bypassed

I'm trying to set up my ASA (running v8.3(1)) to allow traffic from my web server on my DMZ to access one of my internal servers (server B) over port 80. I have configured the static translation to translate from my DMZ ip address scheme to the IP address of the internal server (server B). I have also set up an ACL that allows traffic from my web server to server B over port 80 (access list is high in order before any deny statements). When I try to access the internal server the packet is getting dropped because of the implicit "deny any any" ACL. It's as though the ACL I've created is getting completely ignored.

Sample config is as follows:

object network obj-web

   nat (inside,dmz) static 1.1.1.1

obj-web address is 2.2.2.2

access-list acl_allow_dmz extended permit tcp host 2.2.2.2 host 1.1.1.1 eq www

What am I missing?

Thanks.

10 REPLIES
Cisco Employee

Re: ASA ACL seems to be being bypassed

Hello,

It seems like the access-list you have configured is using the translated IP, not the real IP. Assume that the inside server IP is 192.168.1.100 and the DMZ range is 172.16.1.x

object network obj-web

host 192.168.1.100

nat (inside,dmz) static 172.16.1.100

In the above configuration, you are mapping 192.168.1.100 to 172.16.1.100. Now, if you want to allow a specific host on the DMZ, say 172.16.1.20, to have access to the inside server, then your access-list will look like

access-list dmz_access_in permit ip host 172.16.1.20 host 192.168.1.100

Here, even though you have mapped the inside IP to 172.16.1.100 on DMZ, due to changes in 8.3 code, you will need to use the real IP in the access-list.

Hope this helps.

Regards,

NT

Community Member

Re: ASA ACL seems to be being bypassed

I had also tried adding the access list using the real inside ip but it didn't work.

Cisco Employee

Re: ASA ACL seems to be being bypassed

Hello,

Can you please share the actual configuration related to this communication here? Also include the ouput of "show run access-group" command.

Regards,

NT

Community Member

Re: ASA ACL seems to be being bypassed

Here's the config information. The only thing I changed was the IP addresses because we can't give those out. The access-group is as follows:

web-server IP: 1.1.1.1

internal server (server B): 2.2.2.2

NATd address: 3.3.3.3

object network obj-2.2.2.2

host 2.2.2.2

description Internal server

object network obj-2.2.2.2

nat (inside,dmz) static 3.3.3.3

access-list acl_dmz extended permit tcp host 1.1.1.1 host 2.2.2.2 eq www

access-list acl_dmz extended permit tcp host 1.1.1.1 host 2.2.2.2 eq https

access-group acl_dmz in interface DMZ

access-group acl_outside in interfae outside

This config accounts for the changes to allow the real IP address.

Cisco Employee

Re: ASA ACL seems to be being bypassed

Hello,

The configuration sample you have provided seems to be correct. If this is not working, then there could be a conflict in the configuration. Is 3.3.3.3 address part of DMZ subnet? Can you run the packet tracer command on the firewall and see if the firewall allows the packet or if it is getting dropped somewhere?

packet-tracer input dmz tcp 1.1.1.1 1024 3.3.3.3 80 detailed

Replace the IP's with the actual IP's and see where exactly it breaks.

Regards,

NT

Community Member

Re: ASA ACL seems to be being bypassed

Yes 3.3.3.3 is part of the DMZ subnet. Here's the weird part...if I run the packet tracer in the ASDM from

interface: DMZ

source ip: web server

dest: real address of internal server

port: 80

The packet is allowed and the rules are getting selected as expected. I'm going to also run a wireshark to see if I can get some information on what else might be happening. But this is strange.

Thanks.

Cisco Employee

Re: ASA ACL seems to be being bypassed

Hello,

Can you run the packet tracer for reverse flow as well?

Interface: Inside

Source: Server B

Destination: Web Server

Regards,

NT

Community Member

Re: ASA ACL seems to be being bypassed

The reverse packet trace allowed the packet as well. The translations and everything worked as I would expect.

Cisco Employee

Re: ASA ACL seems to be being bypassed

Hello,

Lets put the capture on the firewall to see if the packet is traversing through the firewall.

access-list capin permit ip host host

access-list capin permit ip host host

capture capin access-list capin interface inside

access-list capdmz permit ip host host

access-list capdmz permit ip host host

capture capdmz access-list capdmz interface inside

Once you configure above lines, please try sending some data from DMZ server to the inside server. Now we can verify if the traffic traversed through the firewall or not using the "show capture " output.

show capture capin

show capture capdmz

Hope this helps us in determining the root cause.

Regards,

NT

Community Member

Re: ASA ACL seems to be being bypassed

So last night I was working on this and thinking about what could be happening. It suddenly occurred to me that in some instances I was using the wrong IP address in the ACL. I figured out that part of my mistake was that I was using the IP address of the website where the requests originate instead of the IP address of the web server itself. That was a stupid mistake on my part.

Today I started modifying my ACLs to structure them so that they are using the actual IP address of the server as well as the real IP address of the internal network server. It appears that these new ACLs are now being used. YAYYYYY!!!!!

One thing I did notice is that in some cases where the NATd IP is used instead of the real IP from the internal server is used the ACL is showing hits. Why do some work this way while others don't? In this same case I see hits on both the old and the new ACL. If I move the new ACL above the old ACL all of my hits go to the new ACL and the counts on the old go to 0. Wierd....why would this happen? Is this supposed to happen?

Thanks.

338
Views
0
Helpful
10
Replies
CreatePlease to create content