09-15-2010 02:11 PM - edited 03-11-2019 11:41 AM
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.
09-15-2010 02:18 PM
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
09-15-2010 02:26 PM
I had also tried adding the access list using the real inside ip but it didn't work.
09-15-2010 02:28 PM
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
09-15-2010 02:40 PM
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.
09-15-2010 02:50 PM
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
09-15-2010 02:54 PM
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.
09-15-2010 02:58 PM
Hello,
Can you run the packet tracer for reverse flow as well?
Interface: Inside
Source: Server B
Destination: Web Server
Regards,
NT
09-15-2010 05:38 PM
The reverse packet trace allowed the packet as well. The translations and everything worked as I would expect.
09-16-2010 05:29 AM
Hello,
Lets put the capture on the firewall to see if the packet is traversing through the firewall.
access-list capin permit ip host
access-list capin permit ip host
capture capin access-list capin interface inside
access-list capdmz permit ip host
access-list capdmz permit ip 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
show capture capin
show capture capdmz
Hope this helps us in determining the root cause.
Regards,
NT
09-16-2010 08:40 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide