Thanks for reading. I'm sure this is elementary (but so am I - heh).
I'm trying to allow connectivity from the private network to a server in my ASA5520 DMZ. I've tried a couple different iterations but no success. Basically, right now, I've got this configured (the 172.31 address is the same on each line):
access-list DMZ-INET extended permint tcp host 172.31.x.x 10.0.0.0 255.0.0.0
access-list DMZ-INET extended permint object-group Dell-DP host 172.31.x.x host 10.0.0.19
access-list DMZ-INET extended permint object-group Dell-DP interface inside host 172.31.x.x
Here's the object group:
object-group service DELL_DP
service-object tcp eq 8443
service-object tcp eq 8888
service-object tcp eq 9000
service-object tcp eq 8081
service-object tcp eq 8000
service-object tcp eq 1099
service-object tcp eq 9011
service-object tcp eq 3389
My desktop is 10.0.0.19. I just want to test with a ping and telnet over the object ports listed. My hit counts are all zeros so I'm out in the weeds somewhere.
Thanks again for reading!
If your connection attempts are coming towards the DMZ network then the DMZ interface ACL wont be the one controlling this traffic (at least in a typical setup). It will be the ACL that controls traffic coming from the interface where your desktop is.
It would be easier to check if we could see more configurations
You can naturally use the "packet-tracer" command to test the ASA configurations
Just replace the above unfilled sections and issue the command and it lists which rules/configurations on the ASA are applied to the packet.
Naturally it might stop at an very early phase if there is a problem with an interface ACL
Thanks for your help!
Here's results of a packet-tracer.
MAC Access list
in 172.31.211.0 255.255.255.0 DMZ-INET
in 10.0.0.0 255.255.224.0 inside
access-group inside_access_in in interface inside
access-list inside_access_in extended permit ip any any
nat (DMZ-INET) 10 172.31.211.0 255.255.255.0
match ip DMZ-INET 172.31.211.0 255.255.255.0 outside any
dynamic translation to pool 10 (126.96.36.199 [Interface PAT])
translate_hits = 0, untranslate_hits = 0
New flow created with id 313103908, packet dispatched to next module
It doesn't ping and it doesn't appear in the arp table. I'll check with the server admin and see what's up with that server: on or off and see what I've got at that point.
The device is powered up but not accessible by the firewall via PING or in the ARP table. What relevant sections of the config would you like to see?
Since I have not seen the actual configuration I am wondering is the DMZ network configured directly to some ASA interface? If it is then you should see the ARP of the server after a ping even if it didnt reply to the ping. If the network is directly connected and you can see the ARP it means there is a problem somewhere between the ASA and the server.
You can naturally ask the server admin to try to ping the DMZ interface IP address and try to confirm connectivity.
I guess we might need to see some configurations to confirm everything on the ASA side but according to the "packet-tracer" the rules would seem to be fine.
Please try the swapping the host address and network address in the acl: DMZ-INET.
I assume acl DMZ-INET is being applied on dmz interface in bound.
access-list DMZ-INET extended permint tcp 10.0.0.0 255.0.0.0 host 172.31.x.x
access-list DMZ-INET extended permint object-group Dell-DP host 10.0.0.19 host 172.31.x.x
Please let me know, if this helps.
Thanks for your comments and guidance. It's much appreciated!
Here's some missing info (which I just sourced from a teammate): my target IP address in the DMZ is actually a VIRTUAL machine. That Sys Admin thought the VM was participating the DMZ simply because he gave it a DMZ address. I think I need to NAT an IP to extend the VMs presence into the DMZ.
I think I should be good after that.