ping fails; traceroute is OK

Would anyone know why ping returns "Destination unreachable", while
traceroute seems to suceed? I thought traceroute used the same packet
headers as ping ... Would anyone know why this ping is failing?

[root@cannes root]# traceroute freedb.org
traceroute to freedb.org (64.71.163.204), 30 hops max, 38 byte packets
1 fox (10.1.1.6) 1.157 ms 0.707 ms 0.690 ms
2 tnt02.wor.conversent.net (216.41.101.22) 163.941 ms 168.609 ms
159.848 ms 3 ma1-bb1-fa0-0-1.conversent.net (216.41.101.24) 159.810
ms 159.605 ms 159.668 ms
4 ct1-bb1-at100-51.conversent.net (206.53.1.30) 159.952 ms 159.555
ms 159.854 ms
5 ct1-bb2-fe0-0-0-0.conversent.net (204.17.65.4) 159.795 ms
159.552 ms 159.854 ms
6 65.89.249.41 (65.89.249.41) 159.804 ms 158.782 ms 159.865 ms
7 P5-0.a0.wash.broadwing.net (216.140.8.81) 169.777 ms 169.592 ms
169.796 ms
8 p0-0-0.a1.wash.broadwing.net (216.140.8.13) 160.540 ms 159.622
ms 159.852 ms
9 mae-east-atm.he.net (198.32.187.19) 169.803 ms 169.600 ms
169.956 ms
10 pos7-0.gsr12012.pao.he.net (216.218.254.205) 239.971 ms 239.385
ms 240.062 ms
11 pos2-0.gsr12012.fmt.he.net (64.62.249.121) 229.967 ms 239.666 ms
239.952
ms
12 freedb.org (64.71.163.204) 249.967 ms 249.636 ms 239.853 ms
[root@cannes root]# ping freedb.org
PING freedb.org (64.71.163.204) 56(84) bytes of data.
From tnt02.wor.conversent.net (216.41.101.22) icmp_seq=1 Dest
Unreachable, Bad Code: 9
From tnt02.wor.conversent.net (216.41.101.22) icmp_seq=2 Dest
Unreachable, Bad Code: 9

I'm using RH 9.0

On 2004-01-08, Alex Krowitz <(E-Mail Removed)> wrote:
> Would anyone know why ping returns "Destination unreachable", while
> traceroute seems to suceed? I thought traceroute used the same packet
> headers as ping

No, traceroute uses UDP with TTL set strategically, while ping uses two
ICMP messages (echo-request and echo-reply). It is not too uncommon for
some administrators to block echo-request, but they are usually dropped,
not responded with "Destination unreachable".

> ... Would anyone know why this ping is failing?

> [root@cannes root]# traceroute freedb.org
> traceroute to freedb.org (64.71.163.204), 30 hops max, 38 byte packets
> 1 fox (10.1.1.6) 1.157 ms 0.707 ms 0.690 ms
> 2 tnt02.wor.conversent.net (216.41.101.22) 163.941 ms 168.609 ms
....
> 12 freedb.org (64.71.163.204) 249.967 ms 249.636 ms 239.853 ms
> [root@cannes root]# ping freedb.org
> PING freedb.org (64.71.163.204) 56(84) bytes of data.
> From tnt02.wor.conversent.net (216.41.101.22) icmp_seq=1 Dest
> Unreachable, Bad Code: 9
> From tnt02.wor.conversent.net (216.41.101.22) icmp_seq=2 Dest
> Unreachable, Bad Code: 9

Lets see, I can ping it successfully, which means its not a fault at
their end (although the fault could have been temporary I suppose).
Since the error is being emitted from tnt02.war.conversent.net, which
is the first router outside of your network, I would suspect either
your ISP is blocking something (and doing a strange job of it), or
there is something peculiar at your end, such as not NATing everything.

The most troubling part is the "Bad Code: 9", as no ICMP message that
is documented in the ICMP RFC has a code value of 9, so find out what's
emitting that.

tcpdump -i <your_outside_iface> icmp
Ping freedb.org

If that doesn't show any information about the ICMP values, do this

tcpdump -w /tmp/icmp.pcap -i <your_outside_iface> icmp
Copy icmp.pcap to a machine with ethereal installed.
ethereal /tmp/icmp.pcap

However, since tnt02 is the next step out of your network, and you are
using a private network, make sure that you are using NAT, although the
fact that traceroute is working would seem to indicate that this is
working, as packets are making their way back to you.

PS. Does it make a difference which host/network you ping?

--
Cameron Kerr
(E-Mail Removed) : http://nzgeeks.org/cameron/
Empowered by Perl!

Alex Krowitz <(E-Mail Removed)> wrote:
> Would anyone know why ping returns "Destination unreachable", while
> traceroute seems to suceed?

I had an email from a nice gentleman about this, though he didn't post
it the newsgroup. It seems that code 9 means that Communication with
Destination Network Administratively Prohibited. Code 10 is the same,
but where the prohibited destination is a host, not a network.

> [root@cannes root]# ping freedb.org
> PING freedb.org (64.71.163.204) 56(84) bytes of data.
> From tnt02.wor.conversent.net (216.41.101.22) icmp_seq=1 Dest
> Unreachable, Bad Code: 9
> From tnt02.wor.conversent.net (216.41.101.22) icmp_seq=2 Dest
> Unreachable, Bad Code: 9

--
Cameron Kerr
(E-Mail Removed) : http://nzgeeks.org/cameron/
Empowered by Perl!

Cameron Kerr wrote:
>>Would anyone know why ping returns "Destination unreachable", while
>>traceroute seems to suceed?

`ping' sends ICMP echo request packets to the hosts and waits for an
ICMP echo reply.
On some sites replying to such an request is disabled due to decreasing
the network traffic.

`traceroute' works different: sents UDP packets (with increasing TTL
values) to the host.

Cameron Kerr <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> Alex Krowitz <(E-Mail Removed)> wrote:
> > Would anyone know why ping returns "Destination unreachable", while
> > traceroute seems to suceed?
>
> I had an email from a nice gentleman about this, though he didn't post
> it the newsgroup. It seems that code 9 means that Communication with
> Destination Network Administratively Prohibited. Code 10 is the same,
> but where the prohibited destination is a host, not a network.
>
> > [root@cannes root]# ping freedb.org
> > PING freedb.org (64.71.163.204) 56(84) bytes of data.
> > From tnt02.wor.conversent.net (216.41.101.22) icmp_seq=1 Dest
> > Unreachable, Bad Code: 9
> > From tnt02.wor.conversent.net (216.41.101.22) icmp_seq=2 Dest
> > Unreachable, Bad Code: 9

This got me to snooping, so here's what I found:
http://www.networksorcery.com/enp/default0504.htm

Note that codes 9 and 10 should have been 13, re:
[quote]
RFC 1812, pages 80 and 82:

The ICMP Destination Unreachable message is sent by a router in
response to a packet which it cannot forward because the destination
(or next hop) is unreachable or a service is unavailable. Examples of
such cases include a message addressed to a host which is not there
and therefore does not respond to ARP requests, and messages addressed
to network prefixes for which the router has no valid route.

A router MUST be able to generate ICMP Destination Unreachable
messages and SHOULD choose a response code that most closely matches
the reason the message is being generated.

[====note para following]
Routers SHOULD NOT generate Code 8; whichever of Codes 0 (Network
Unreachable) and 1 (Host Unreachable) is appropriate SHOULD be used
instead. (sic)Codes 9 and 10 were intended for use by end-to-end
encryption devices used by U.S military agencies. Routers SHOULD use
the newly defined Code 13 (Communication Administratively Prohibited)
if they administratively filter packets.

Routers MAY have a configuration option that causes Code 13
(Communication Administratively Prohibited) messages not to be
generated. When this option is enabled, no ICMP error message is sent
in response to a packet that is dropped because its forwarding is
administratively prohibited.
[end quote]

Wonder where this router has seen service? Maybe it's the net police
protecting us from the nefarious likes of freedb.org:
http://freedb.org/modules.php?name=S...rticle&artid=2

Thanks to the nice gentleman who roused my curiosity.

regards
prg
email above disabled

Alex Krowitz wrote:

> Would anyone know why ping returns "Destination unreachable", while
> traceroute seems to suceed? I thought traceroute used the same packet
> headers as ping ... Would anyone know why this ping is failing?
>

Ping uses an ICMP message, which may be ignored by the destination or
blocked by routers along the path. Traceroute normally uses a udp packet
and not an ICMP message. The reason for this, is that traceroute relies on
ICMP timeout messages, to determine how far it reached. However, ICMP
messages are not suppose to be generated for failed ICMP messages.

--

Fundamentalism is fundamentally wrong.

To reply to this message, replace everything to the left of "@" with
james.knott.

Thank you for your helpful response. I first looked at pinging other
hosts and networks, as you suggested. It seems that all of my pings
result in the same error, regardless of host and network.

I'm using dnsmasq on my firewall machine, so I tried tweaking my
configuration, but that didn't help.

I dropped all my iptables filter rules, keeping the nat table. The
simplified nat table is listed below.

# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

traceroute still works and ping still fails at this point. My next
step is to follow up on your tcpdump suggestion ... I have snort
installed, but I'm still finding my way around with it.

Alex Krowitz <(E-Mail Removed)> wrote:
> Thank you for your helpful response. I first looked at pinging other
> hosts and networks, as you suggested. It seems that all of my pings
> result in the same error, regardless of host and network.

Ask your service provider. That's where the problem is coming from, it
would seem. You may need to ask to get bumped up a tier or two from the
helpdesk, but it should be a fairly common question.

--
Cameron Kerr
(E-Mail Removed) : http://nzgeeks.org/cameron/
Empowered by Perl!

Alex Krowitz <(E-Mail Removed)> wrote:
> Thank you for your helpful response. I first looked at pinging other
> hosts and networks, as you suggested. It seems that all of my pings
> result in the same error, regardless of host and network.

Your ISP is almost certainly blocking ping requests. A ping request is
is specified in the Internet Control Message Protocol (ICMP), which is
mostly used for messages between hosts (as opposed to humans) regarding
selected parts of the IP layer. Ping requests and replies are exceptions.

Not long ago a MS virus (I think it was W32/Sobig.f@MM) used ping
requests to detect potential victims and some ISPs (including mine)
now block all ping requests. In fact, mine apparently also blocks the
ICMP TTL exceeded message necessary for traceroute to work with UDP.

> I'm using dnsmasq on my firewall machine, so I tried tweaking my
> configuration, but that didn't help.

I'd be very surprised if anything you do could help, including complaining
to the ISP.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* Better is the enemy of good enough. */