why only some ips work?

Those look a little dodgy to me. The first thing worth noting is that the traceroute to 209.151.137.78 does not, in fact, go by

209.151.137.73, unless something funky is happening.

The double .78 at the end of your second traceroute looks a little dodgy, too - I'm certain it means *something*, but I don't know what.

I'd like to take a look at the routing tables for 209.151.129.250 and ..204. And possibly .78.

Do you allow tracerouting? If not, that might explain the 'timed out' messages in your first traceroute.

Running tcpdump on .73 and .78 may be interesting; it will at least allow you to see if anything happens on the wire.

Joachim

Why such an obsolete distribution? RH8.0 was end-of-lifed at Red Hat on

31 December 2003, and support at fedoralegacy.org ended in September 2004.

Look at the forwarding rules on .73, and the firewall rules on .74

Is the Linux box offering services to the Internet? Try connecting to that service. If not offering services, why is it connected?

That looks like the b0rken microsoft TRACERT program, which only uses ICMP echos. The original 'traceroute' uses UDP packets to ports in the

33434 and above range. Different protocols - different results. None of them relate to what you might see with TCP.

The host beyond janefinch-core.ica.net is blocking ICMP Type 3, or not forwarding properly.

If that's not a typo, there is something screwy with the networking setup on 209.151.137.78 - possibly a strange firewall rule. If that is RH8.0, there was a "user friendly" P.O.S called 'lokkit' that was used to work with the firewall. Or, you could just use '/sbin/iptables -L' to see what rules are in place.

Old guy

:> Tracing route to 209.151.137.78 over a maximum of 30 hops

:> 11 22 ms 23 ms 50 ms 209.151.137.204 :> 12 21 ms 29 ms 30 ms 209.151.137.78 :> 13 22 ms 22 ms 22 ms 209.151.137.78

:The double .78 at the end of your second traceroute looks a little :dodgy, too - I'm certain it means *something*, but I don't know what.

NAT'ing router with the real host being "inside".

The TTL expires on one packet when it reaches the router, and the next round with a TTL one higher expire when they hit the host. The host is NAT'd to the public IP, though, so the icmp comes back from the same IP address as before.

My conjecture is that 209.151.137.204 doesn't have a route to 209.151.137.73 . Perhaps it has a host route to 209.151.137.78 . If 209.151.137.78 is a router, it could be advertising a route to itself, whereas there is nothing to advertise the route to

209.151.137.73 so 209.151.137.204 doesn't know to answer -- that the last hop that has a static route for the block is the one before 209.151.137.204 .

Hmm, that would work, but why would the router forward it when it's sent to it's own IP? Or, if it does not consider .78 to be it's own IP, why does it accept packets and decrease TTL for that address?

I'm just trying to learn something new here...

That sounds reasonable.

Joachim

In article , Joachim Schipper wrote: :Walter Roberson wrote: :> NAT'ing router with the real host being "inside".

:> The TTL expires on one packet when it reaches the router, and :> the next round with a TTL one higher expire when they hit the host. :> The host is NAT'd to the public IP, though, so the icmp comes back :> from the same IP address as before.

:Hmm, that would work, but why would the router forward it when it's sent :to it's own IP? Or, if it does not consider .78 to be it's own IP, why :does it accept packets and decrease TTL for that address?

In this scenario, the host itself is likely using a private IP address. The first bunch of packets expire at the router itself and the icmp unreachable get sent back normally, from the router's IP.

The second bunch of packets are forwarded to the private IP, a process that changes the destination IP address but not the source IP addresses. The host replies with icmp port-unreachable, with the private IP as the source and the probing host's IP as the destination (read off of the incoming packet). The private source IP of the host is nat'd as it heads out the router, and the embedded IP address of the icmp port-unreachable is probably nat'd to the public IP too. The port-unreachable makes it back to the probing host and the host knows to stop the traceroute.

This is slightly different than I was indicating before, in that before I was indicating ttl-exceeded for the inside host, but that didn't take into account that the traceroute stopped at that point, which only happens with port-unreachable.

For this scenario to work, it has to be a -router- that is doing the NAT. If it is a firewall such as the Cisco PIX, then the firewall is not supposed to examine the TTL -- a firewall is supposed to be transparent that way.