Link to home
Start Free TrialLog in
Avatar of Netexperts
NetexpertsFlag for United Kingdom of Great Britain and Northern Ireland

asked on

ASA 5505 Version 8.3 and ASDM version 6.3 showing NO ROUTE TO HOST on PING

Hi Guys,

I am totally new to Cisco and have had help in setting up a new Cisco ASA 5005 from another post in EE and have had it checked by a Cisco guy who has confirmed it looks ok with the Rules etc however we still have no Internet connection.
I have tried to PING the Google DNS servers of but no matter which Interface i select (we have Inside, outsdie and DMZ) it just shows 'No route to host' Success rate is 0 percent (0/1)
Is there anything i need to set up on the Interfaces at all ?

Avatar of Netexperts
Flag of United Kingdom of Great Britain and Northern Ireland image


Just to add that i can ping the WAN IP successfully from the Cisco if that helps
Have you configured a default route on the ASA?

route outside <ISP address>
I've just added a static route as:
Interface Outside
IP Address
Gateway (WAN IP)
Metric 1  

and it now doesn't show the 'No route...' error although now just shows
 'Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 0 percent (0/5)

ICMP is not stateful and the ASA may not be allowing replies in.  Configure "icmp permit any Outside" to allow external hosts to ping the ASA.  You can also enable application inspection of the ICMP traffic by adding ICMP to the inspect list in the global policy at the bottom of the CLI config.
Just checked my ASA config.  I have the policy inspection configured but not the 'icmp permit any outside' and I can ping Google DNS.  Try adding the application inspection:

policy-map global_policy
 class inspection_default
  inspect icmp
Avatar of Pete Long
>> have the policy inspection configured but not the 'icmp permit any outside'

ICMP is allowed for connected networks by default:)

do you get the same result from ping that's what I usually test with?

Can you give me the command to add the application inspection ?
Avatar of alex_firewall_guy

policy-map global_policy
 class inspection_default
  inspect icmp
We also use the following commands

icmp unreachable rate-limit 1 burst-size 1
icmp permit host internet
icmp permit any echo-reply internet
icmp permit any time-exceeded internet
icmp permit any unreachable internet
icmp deny any internet
icmp permit any inside
Any luck yet?
Still having the same problem but we can do a TCP packet trace on the inside interface from an internal address to an external IP successfully but the same trace on the outside interface fails with the error "(acl-drop) Flow is denied by configured rule"

I've attached a screenshot of the access rules as they show in the ASDM.  Is there anything obviously wrong?

Thanks User generated image
you have an implied ACL allowing outbound traffic (inside to any less secure interface)

You don't have any explicit ACLs that would allow you to initiate traffic from the outside coming back in.

Are you now able to do the pings that you couldn't do as part of your original post?
No, the ping to still fails for all interfaces but now we get a timeout error rather than a no route error.

Sorry this is really basic but how do I setup explicit ACLs to get the traffic coming back in?
do have access to the CLI on the ASA or are you strictly using ASDM?

If you have CLI access, issue a "show running-config" and capture that output and post it here (remember to remove your passwords and sanitize it before posting it).  Once you have that posted, I should be able to help a little better.  I am concerned that your ping still isn't working.  If you have a default route out your wan interface and you setup the icmp commands like I posted previously, you should be able to ping from the firewall to without any problems.  I took a blank 5505 and slapped an IP on it, a default route on it, the icmp commands like I posted previously and connected it to my internet pipe and can ping from the ASA to so I am confused why that still isn't working for you.  
We've got CLI access as well, the running config is below. I'm sure it's something we've already put in that's causing the problem but can't see itfor looking.

ASA Version 8.3(1)
interface Vlan1
 nameif inside
 security-level 100
 ip address

interface Vlan2
 nameif outside
 security-level 0
 ip address <Outside IP>

interface Vlan5
 nameif dmz
 security-level 50
 ip address

interface Ethernet0/0
switchport access vlan 2

interface Ethernet0/1

interface Ethernet0/2

interface Ethernet0/3

interface Ethernet0/4

interface Ethernet0/5

interface Ethernet0/6

interface Ethernet0/7

no ftp mode passive
object network obj_any
pager lines 24
logging enable
logging asdm informational
mtu inside 1500
mtu outside 1500
mtu dmz 1500
no failover
icmp unreachable rate-limit 1 burst-size 1
icmp permit host inside
icmp permit any inside
icmp permit any echo-reply outside
icmp permit host outside
icmp permit any time-exceeded outside
icmp permit any unreachable outside
icmp deny any outside
no asdm history enable
arp timeout 14400
nat (inside,outside) source dynamic any interface

object network obj_any
nat (inside,outside) dynamic interface
route outside <Outside IP> 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
dynamic-access-policy-record DfltAccessPolicy

http server enable
http inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
telnet inside
telnet timeout 5
ssh timeout 5
console timeout 0
dhcpd auto_config outside

dhcpd address inside
dhcpd enable inside

threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept

class-map inspection_default
 match default-inspection-traffic

policy-map type inspect dns preset_dns_map
  message-length maximum client auto
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect esmtp
  inspect sqlnet
  inspect skinny  
  inspect sunrpc
  inspect xdmcp
  inspect sip  
  inspect netbios
  inspect tftp
  inspect ip-options
  inspect icmp

service-policy global_policy global
prompt hostname context
: end
as long as by outside ip on this line

route outside <Outside IP> 1

you mean the ip of your next hop (your internet edge router, your dsl modem, your cable modem, etc) and not the outside ip of the ASA that you configured for the interface vlan 2 in this section,

interface Vlan2
 nameif outside
 security-level 0
 ip address <Outside IP>

you should be able to ping from the ASA to for certain and to just about anything else based upon the icmp you have allowed on your outside interface with these two commands

icmp permit any echo-reply outside
icmp permit host outside

your nat config and the lack of access-list entries and access-groups could cause issues getting traffic through the ASA but those things won't cause you any concern with step one which would be to just get a ping from the ASA to or to any other ip address outside your ASA to succeed.

I applied your same config as you have here on a 5505 using one of my public addresses as the vlan 2 address and using my test bench internet edge router as the destination on the route statement and was able to ping  If you have the default route set right for the next hop, then it may something configured on your upstream (your edge router, your dsl modem, your cable modem, etc) that is causing you these headaches.

Let me know if any of this helps or not and good luck :)

Thanks Alex,

I had the same IP in the route as on the outside interface, putting the next Ip of the next hop has fixed the ping issue and that part's now working.  

I'll have a look at the NAT and access rules now.
Avatar of alex_firewall_guy

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
The new rules are giving web access, looks like we're there.
Thanks for help
Alex the firewall guy got us to the root of the problem which helped us fix the general access issues.

Polite, helpful and knowledgeable
Thanks for the kind words.  I am just glad I was able to help.  :)