topic Re: ASA ACL seems to be being bypassed in Network Security

ASA ACL seems to be being bypassed

snowmizer — Mon, 11 Mar 2019 18:41:02 GMT

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.

Re: ASA ACL seems to be being bypassed

Nagaraja Thanthry — Wed, 15 Sep 2010 21:18:15 GMT

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,

Re: ASA ACL seems to be being bypassed

snowmizer — Wed, 15 Sep 2010 21:26:36 GMT

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

Re: ASA ACL seems to be being bypassed

Nagaraja Thanthry — Wed, 15 Sep 2010 21:28:52 GMT

Hello,

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

Regards,

Re: ASA ACL seems to be being bypassed

snowmizer — Wed, 15 Sep 2010 21:40:34 GMT

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.

Re: ASA ACL seems to be being bypassed

Nagaraja Thanthry — Wed, 15 Sep 2010 21:50:22 GMT

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,

Re: ASA ACL seems to be being bypassed

snowmizer — Wed, 15 Sep 2010 21:54:14 GMT

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.

Re: ASA ACL seems to be being bypassed

Nagaraja Thanthry — Wed, 15 Sep 2010 21:58:08 GMT

Hello,

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

Interface: Inside

Source: Server B

Destination: Web Server

Regards,

Re: ASA ACL seems to be being bypassed

snowmizer — Thu, 16 Sep 2010 00:38:57 GMT

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

Re: ASA ACL seems to be being bypassed

Nagaraja Thanthry — Thu, 16 Sep 2010 12:29:15 GMT

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

capture capin access-list capin interface inside

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,

Re: ASA ACL seems to be being bypassed

snowmizer — Thu, 16 Sep 2010 15:40:57 GMT

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.