Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > Tracert returns same IP address two or three times

Reply
Thread Tools

Tracert returns same IP address two or three times

 
 
david.braesicke@gmail.com
Guest
Posts: n/a
 
      04-08-2005
Here's an example:
C:\>tracert 10.162.248.1

Tracing route to 10.162.248.1 over a maximum of 30 hops

1 1 ms 1 ms 1 ms 10.162.242.1
2 6 ms 6 ms 6 ms 10.161.225.233
3 6 ms 6 ms 6 ms 10.162.248.1
4 7 ms 7 ms 7 ms 10.162.248.1

Trace complete.

Is this some sort of loop? This is new network with many remote sites
connected via t1's.

David

 
Reply With Quote
 
 
 
 
Brad
Guest
Posts: n/a
 
      04-08-2005
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:

http://www.visualware.com/resources/...s/tracert.html

 
Reply With Quote
 
 
 
 
DigitalVinyl
Guest
Posts: n/a
 
      04-08-2005
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

>Here's an example:
>C:\>tracert 10.162.248.1
>
>Tracing route to 10.162.248.1 over a maximum of 30 hops
>
> 1 1 ms 1 ms 1 ms 10.162.242.1
> 2 6 ms 6 ms 6 ms 10.161.225.233
> 3 6 ms 6 ms 6 ms 10.162.248.1
> 4 7 ms 7 ms 7 ms 10.162.248.1
>
>Trace complete.
>
>Is this some sort of loop? This is new network with many remote sites
>connected via t1's.
>
>David


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)
 
Reply With Quote
 
Brad
Guest
Posts: n/a
 
      04-08-2005
If a firewall is letting a traceroute through and/or responding to one
then it's more of a paperweight than a firewall.

 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      04-08-2005
In article <(E-Mail Removed) .com>,
Brad <(E-Mail Removed)> 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".

--
"Who Leads?" / "The men who must... driven men, compelled men."
"Freak men."
"You're all freaks, sir. But you always have been freaks.
Life is a freak. That's its hope and glory." -- Alfred Bester, TSMD
 
Reply With Quote
 
Brad
Guest
Posts: n/a
 
      04-08-2005

> 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.

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.

> 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...


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.

> 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...


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.

> 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


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.

> 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.

 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      04-09-2005
In article <(E-Mail Removed). com>,
Brad <(E-Mail Removed)> 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
ort 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 .
http://mirror.sg.depaul.edu/pub/Open...e/traceroute.c


: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
ne 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:

www.apple.com 15 of 17 hops respond, including endpoint response
www.cia.gov 14 of ?? hops respond
www.cisco.com 18 of 18 hops respond, including endpoint response
www.counterpane.com 16 of 17 hops respond, including endpoint response
www.google.com 15 of 15 hops respond, including endpoint response
www.hp.com 20 of ?? hops respond
www.microsoft.com 12 of ?? hops respond
www.reuters.co.uk 19+ of ?? hops respond (router loop)
www.slashdot.com 19 of 19 hops respond, including endpoint response
www.sony.com 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.

http://www.die.net/doc/linux/man/man8/traceroute.8.html

http://bama.ua.edu/cgi-bin/man-cgi?traceroute+1M

http://www.hmug.org/man/8/traceroute.html

http://techpubs.sgi.com/library/tpl/...1/traceroute.z

--
"[...] it's all part of one's right to be publicly stupid." -- Dave Smey
 
Reply With Quote
 
Brad
Guest
Posts: n/a
 
      04-09-2005
None of that holds true if your tracerouting from a windows box which
the original posts indicates is the case.

 
Reply With Quote
 
DigitalVinyl
Guest
Posts: n/a
 
      04-09-2005
"Brad" <(E-Mail Removed)> 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 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)
 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      04-09-2005
In article <(E-Mail Removed) .com>,
Brad <(E-Mail Removed)> 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.
--
Usenet is like a slice of lemon, wrapped around a large gold brick.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Three Mobile --> Skype on three (Non-three [Symbian - Nokia] handsets) Harry Stottle UK VOIP 0 01-05-2010 08:59 AM
Strange IP Address with Tracert, anyone know? MuteAnt Computer Security 1 12-07-2006 09:23 PM
how to use same user control x number of times on same asp page David Hubbard ASP .Net 2 01-12-2006 03:56 PM
Get the same selected date from the calendar two consecutive times =?Utf-8?B?bWc=?= ASP .Net 2 06-02-2004 10:21 AM
I'm sorry for post same message three times by mistalke! walker C Programming 1 11-24-2003 08:51 PM



Advertisments