Tracert returns same IP address two or three times

No loop, #3 and #4 are the same device. It just used the same IP for it's source address in the ICMP TTL expired msg and the icmp echo reply msg.

If you research the way traceroute (in windows) works this makes sense. Check out:

I've seen this with some brands of firewalls. Either both are the firewall or the first 10.162.248.1 was the firewall, then next is an end device. I think that was with Checkpoint or Pix that I experienced that-but honestly can't remember exactly which. And of course, your particular config makes a world of difference.

DiGiTAL_ViNYL (no email)

If a firewall is letting a traceroute through and/or responding to one then it's more of a paperweight than a firewall. :-)

In article , Brad wrote: :If a firewall is letting a traceroute through and/or responding to one :then it's more of a paperweight than a firewall. :-)

I'm not convinced that what you say is true.

We use public IP addresses for all of our servers that there is outside access to -- we have to do so in some cases, as NAT is incompatible with some networking technologies. We allow traceroute to narrow bands of ports (the two most common ranges) on a few of those servers; everything else (other servers and all internal-only systems) we do not allow it to.

As the IPs in question are public IPs that are easily associated with us (e.g., whois would tell you the CIDRs if you know the simple keywords to ask for), traceroute to them is not going to reveal any internal information about our systems... other than the detail that we allow traceroute to them. People aren't going to be able to connect to any real service on those ports as the systems in question never dynamically allocate those ranges as destination ports.

Thus nothing is leaked about our internal structure that isn't already deducable to anyone who spent a few minutes looking.

On the other hand, the ability to traceroute to those selected systems performs the useful network management function of allowing us to track down networking issues more easily -- track down whether, for example, the service is unreachable or the host is unreachable or whether it is a VPN problem, or whether a #@$ DSL modem has frozen again...

Recall that real-life security is not about blocking every *possible* problem: real-life security is a matter of risk/benefit analysis. If we get benefits from permitting selected traceroute that save us noticable time and money in network debugging, and if the risk involved with permitting the traceroute is small compared to other issues, then I don't see how one could validly say that it is "more of a paperweight than a firewall".

everything

There are two types of traceroutes. Windows products use ICMP/ICMP while many UNIX flavors use UDP/ICMP. With the ICMP/ICMP no ports are used since ICMP rides inside of IP. With UDP/ICMP, UDP uses a RANDOM high port number as the destination port so there's no way to know what port to keep open. Feel free to do some research on the way traceroute actually functions.

keywords

If I can traceroute to your systems then I can map your network which is quite revealing...If your letting in UDP than I can use inverse scans to find out what services are running on your hosts.

systems

I have no problem with being able to traceroute within a network but no one should be able to traceroute from outside your network to inside your network.

Most routers on the Internet will block ICMP TTL expired messages anyways (that's why you get asterisks in the traceroute output) so the value of a traceroute used on the Internet is quite negligible.

paperweight

I hope that makes it clearer.

In article , Brad wrote: :There are two types of traceroutes. Windows products use ICMP/ICMP :while many UNIX flavors use UDP/ICMP. With the ICMP/ICMP no ports are :used since ICMP rides inside of IP. With UDP/ICMP, UDP uses a RANDOM :high port number as the destination port so there's no way to know what :port to keep open. Feel free to do some research on the way traceroute :actually functions.

Your information is incomplete. Most Unix traceroutes use port numbers that increment off of a constant (to the program) base, with the increment being one port per hop (e.g., TTL++, port++). The port number is NOT random: it is confined to small ranges near the common base ports. There are two common base ports, the most common of which (by far) starts at 33434. A quick peak at the OpenBSD source for traceroute shows that that port number breaks down in the source as 32768+666 .

:If I can traceroute to your systems then I can map your network which :is quite revealing

All you can "map" is the existance of the few machines to which we allow traceroute -- machines whose identities are fairly easy to discover for anyone who takes the time to do a bit of research.

:...If your letting in UDP than I can use inverse :scans to find out what services are running on your hosts.

All you can find is the 'port unreachable' to the narrow range of ports we allow. As I indicated in my previous posting, on those servers no process ever uses the port ranges in question. As I indicated earlier, we do not allow general UDP, we only allow a very confined port range.

:I have no problem with being able to traceroute within a network but no :one should be able to traceroute from outside your network to inside :your network.

The justifications you gave for this do not hold up if one manages the port range appropriately.

Meanwhile, we have telecommuters and remote offices. Of course we have VPNs to the remote offices, but if the remote firewall is not responding, we need a way to check to find out whether the problem is with the VPN or with the firewall in general, so it is not rare for me to log in from work to my home system so as to get a reachability opinion from another viewpoint.

:Most routers on the Internet will block ICMP TTL expired messages :anyways (that's why you get asterisks in the traceroute output) so the :value of a traceroute used on the Internet is quite negligible.

"Most routers" ? You have studies to back that up?

Starting from one of my machines at work, I find the following:

15 of 17 hops respond, including endpoint response 14 of ?? hops respond 18 of 18 hops respond, including endpoint response 16 of 17 hops respond, including endpoint response 15 of 15 hops respond, including endpoint response 20 of ?? hops respond 12 of ?? hops respond 19+ of ?? hops respond (router loop) 19 of 19 hops respond, including endpoint response 21 of 21 hops respond, including endpoint response

The above is not "selective editing" -- those are the systems I tried, and those are the results I got.

:> I don't see how one could validly say that it is "more of a paperweight :> than a firewall".

:I hope that makes it clearer.

Sorry, no it doesn't -- what it seems to indicate is that you have not read the traceroute source, nor even the traceroute man page of common traceroute implimentations such as for Linux or Solaris or Mac OSX or IRIX. Experimentally, your statistics also appear to be unjustified. Perhaps you would care to re-examine your arguments.

None of that holds true if your tracerouting from a windows box which the original posts indicates is the case.

I configure our firewalls to allow us to conduct traceroutes from network administrator stations. General population or external doesn't need that priv but hiding the network from the admins just makes things more difficult. DiGiTAL_ViNYL (no email)

In article , Brad wrote: :None of that holds true if your tracerouting from a windows box which :the original posts indicates is the case.

Hmmm, I seem to be a bit dense tonight. Could you perhaps re-explain how those "most" internet routers that supposedly disallow TTL Exceeded messages know whether the TTL Exceeded message was generated in response to a Windows box or a non-Windows box?

Also, do I have the attributions wrong, or was it not you that said that traceroute uses a random UDP port? I don't quite see how my evidence that traceroute does NOT use a random UDP port is negated by the fact that Windows tracert uses icmp. Either you agree that we are discussing two different programs with different modes of operation (traceroute vs tracert), or else your statement about the random UDP port was incorrect anyhow.

I think he was talking about blocking the UDP messages that Unix traceroute sends, not the TTL Exceeded messages sent back by the routers. But this type of filter won't affect Windows TRACERT, because it uses ICMP Echo instead of UDP. If you want to allow pings, you effectively allow TRACERT as well.

But there are many sites that also block ICMP Echo, which will hamper both ping and TRACERT. Try

for instance.

While it's not a totally random port, it's also not a single, static port. Assuming the user doesn't override the default with the -p option, the port that a particular router or firewall will still depend on how many hops away the sender is, because the port number is incremented for each hop. So if you want to block the traceroute ports, you have to block a fairly large range.

There are traceroute variants that can use TCP probe packets with given destination ports, e.g.

lft -d 80

tcptraceroute 80

Trying not to pick on Microsoft here, because many places have similar filters. Anyway, these tools can be very useful for diagnosis. (Of course they should only be used in the crafty hands of certified gurus, not by mere mortals ;-)

And just to divert this conversation even farther from the original topic...

Note that on many Unix versions of traceroute, you can use the "-I" flag to use ICMP ECHO requests (like Windows TRACERT) rather than "high-port" UDP packets as probes.

Unless I'm mistaken, Van Jacobson used UDP probes rather than ICMP ECHO probes, because at the time traceroute was written, some routers (which were prbably called "gateways" then :-) didn't send ICMP TTL Exceeded packets in response to ICMP (ECHO) packets. RFC 792, which originally defined ICMP in 1981, contained this phrase:

To avoid the infinite regress of messages about messages etc., no ICMP messages are sent about ICMP messages.

RFC 1122 (which, together with RFC 1123, contains many important corrections and clarifications on the "early" RFCs) restricted this to "no ICMP error messages are send about ICMP errors" (section 3.2.2):

An ICMP error message MUST NOT be sent as the result of receiving:

• an ICMP error message, or

[...other types of packets, orthogonal to ICMP...]

But that one only came out in 1989, when traceroute had already been written.

Oops, I could just have Google to come up with the authoritative explanation: