Link to home
Start Free TrialLog in
Avatar of omniumnetworking
omniumnetworking

asked on

Cisco ASA5505 can't ping external interface and odd rules

User generated imageUser generated imageWe have an ASA5505 with ASA version 8.3(1) and ASDM version 6.4(5)

For the life of me just can't get it to respond to pings from the outside. We use this to monitor uptime and we need to get it working ASAP.

The syslog continually reports:
Denied ICMP type=8, code=0 from ip_of_our_monitoring_service on interface ATT

We have created an Access Rule to Permit ICMP echo to the ATT interface, but still can't ping it. Also, we have 2 global rules (one which is not enabled) and 3 really odd NAT Rules (the last 3)  which were not created by me and I'm not really sure why they are there. However, disabling the Global Permit rule immediately breaks the Internet.

Can you guys suggest how to 1) allow pinging of the ATT (external) interface from the outside and 2) Configure the device with the minimum amount of required rules

I should clarify this is a super simple setup. Office with a little over a dozen users, Windows PDC server, remote desktop to the server and a couple of other machines for remote administration purposes, plus uptime monitoring with Nagios (those are the ports 12489 and 5666.) As far as routing, the device is not doing anything you couldn't achieve with a cheapo Linksys router.

Attached are images of the main config areas. I entered the IPs of a couple of objects in red just to clarify what those are.

Thanks!
ASKER CERTIFIED SOLUTION
Avatar of Jan Bacher
Jan Bacher
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of omniumnetworking
omniumnetworking

ASKER

Ahh, well I found the pinging problem. In Device Management>Management Access>ICMP> there was a rule: ATT, permit, 0.0.0.0, 0.0.0.0, echo-reply

I changed "echo-reply" to "echo" and now I can ping the interface. I'm still concerned about all those other rules. Should they exist there?
I don't work with ASDM and don't know what the "global" section applies to but the other rules look explicit.  Without seeing the access-lists and access-group statements, I can't confirm 100% but it doesn't seem properly restricted.
Here are access-list and access-group:
access-list ATT_access_in extended permit tcp any interface ATT object-group Rackspace
access-list ATT_access_in extended permit udp any interface ATT eq ntp
access-list ATT_access_in extended permit object-group TCPUDP any interface ATT object-group TripRDP
access-list ATT_access_in extended permit object-group TCPUDP any interface ATT object-group MarcRDP
access-list ATT_access_in extended permit object-group TCPUDP any interface ATT object-group CordDP
access-list ATT_access_in extended permit object-group SNMP any interface ATT
access-list ATT_access_in extended permit object-group Camera any interface ATT
access-list ATT_access_in extended permit object-group TCPUDP any interface ATT eq www
access-list ATT_access_in extended permit tcp any interface ATT eq https
access-list ATT_access_in extended permit tcp any interface ATT eq ftp
access-list ATT_access_in remark Trip RDP
access-list ATT_access_in_1 extended permit object-group TCPUDP any eq 3389 object xxxpdc1 eq 99990
access-list ATT_access_in_1 extended permit object-group NAGIOS object omni object xxxpdc1
access-list ATT_access_in_1 extended permit object-group TCPUDP any eq 3389 object TripW eq 99991
access-list ATT_access_in_1 extended permit object-group TCPUDP any eq 3389 object Marcella eq 99992
access-list global_access extended permit ip any any
access-group ATT_access_in_1 in interface ATT
access-group global_access global

Thanks for your help!
I just wanted to pipe in on the global ACL.  Personally I don't like it but I can see its uses.  Global applies to inbound on ALL interfaces.  It also changes default behavior.

Default behavior with no ACLs defined
traffic from higher security interface to lower is allowed
lower to higher is denied

behavior with ACLs on interfaces (no global defined yet)  these are interface ACLs
looks at entries in ACL only
If no matches are found, it uses an implicit deny

behavior with global ACL and no interface ACL
looks at entries in ACL only
has implicit deny at end if no match found

behavior with interface and global ACLs
check entries in interface ACL first
if no match check global ACL
if no match implicit deny

The reason I don't like the global ACL is because lets say you don't apply an ACL to the inside interface, you believe that since it has a security-level of 100 that it will by default allow all traffic.  However you configured a single rule in the global ACL to ensure ICMP is allowed in on all interfaces.  Guess what you just overroad the default behavior on the inside interface and only ICMP traffic is now allowed regardless of the security level you have configured.  With that said, it is nice if you have ACLs on all interfaces and you have certain rules you want to apply to all interfaces.  Cuts down on duplicate configuration.
so in your case, you are allowing all traffic (ip any any permit) on all interfaces (at least thru the ASA) pretty much removing most of the reason to run a firewall because of how your global ACL is configured.


run
no access-list global_access extended permit ip any any
no access-group global_access global

but get rid of the global rule you're defining.  It opens your ASA way too much.
I would not run the commands Cyclops has mention right away.  Though I agree that the permit ip any any in the global should not be there, but I suspect that it was put there by someone who did not know how to correctly configure the ASA and needed to get things working.

Before removing those commands you would need to analyze the traffic and identify what ports need to be opened.  Once that is done, you can go ahead and remove those commands.
MAG03 raises a very good point.  Sorry, I guess I just assumed all necessary permits where on the interface ACL.  Definitely analyze the traffic first before starting to deny traffic to ensure no needed traffic gets denied.  

Personally what I would do is setup a Splunk instance on a server and configure the ASA to forward syslog to it.  Then I would change the ip any any permit on the global to log as well.  This will create a lot of traffic.  potentially more than a free license of splunk will allow.  If this is the case, let it collect data for about a week then turn off logging.  When you try to log too much it will still index but not allow you to search until you are indexing below your "free" daily limit; thus why shutting it off is good.  I say splunk because I've found it to be the best syslog tool for searching logs easily.  you should be able to more easily pick out what traffic is moving thru your ASA and see if you want to allow it or not.  If you do, create an ACL entry on an ACL applied to an interface.  Once done, then remove the global permit ip any any