ASA ACL seems to be being bypassed

Unanswered Question
Sep 15th, 2010

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Nagaraja Thanthry Wed, 09/15/2010 - 14:18

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

snowmizer Wed, 09/15/2010 - 14:26

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

Nagaraja Thanthry Wed, 09/15/2010 - 14:28

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

snowmizer Wed, 09/15/2010 - 14:40

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.

Nagaraja Thanthry Wed, 09/15/2010 - 14:50

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

snowmizer Wed, 09/15/2010 - 14:54

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.

Nagaraja Thanthry Wed, 09/15/2010 - 14:58

Hello,


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


Interface: Inside

Source: Server B

Destination: Web Server


Regards,


NT

snowmizer Wed, 09/15/2010 - 17:38

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

Nagaraja Thanthry Thu, 09/16/2010 - 05:29

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

snowmizer Thu, 09/16/2010 - 08:40

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.

Actions

This Discussion