Tracert Private IP returns IP

[maboroshi]

Hello everyone I am a bit confused

I tracerted a private ip 192.168.1.1 I do not have a computer associated with this address or am I currently on a network

So after doing this I find it returns the IP of the default gateway of my ISP

My confusion lies in the fact that I should not be able to return an IP from tracerouting a private network so my question why is it doing this or am I incorrect as to the use of tracert

Cheers Maboroshi

[maboroshi]

hmm reading other posts maybe... this is just a theory... the remote management option is available on the router for the gateway interesting indeed. But as I did a port scan of that IP there is only port 110 that is open on that address

Any ideas

[bad_brain]

was the router provided by the ISP?
if yes it may be pre-configured by the provider. do you have only one network card? if yes all traffic has to go through the router first...but it still is pretty weird that a private IP request is routed to the ISP when the IP don´t exist, so check the firewall config of the router...

[maboroshi]

well from what it seems

lets recap

I first tracert 192.168.1.1 it returns the DNS Default Gateway IP ( I am still confused about this )

I then run tracert on 192.168.1.1 with an etheral packet capture in promiscuous mode it returns the ips on the internal network by sending an arp request to each system over each hop

I then tracert the IP of the gateway system with the ethereal packet capture it returns the same results

So in theory I wasted my time looking into all this cause I can accomplish the same results with the tracert of the default gateway IP

I then tracert another private address (192.168.1.100) it returns the default gateway yet again

Lets Recap about my system

I am not behind a router I am running a straight connection to the internet I have a software firewall

So my question is back to the first one I asked and after all this research I am still confused about my ISP and why if I tracert a private IP it returns there Network Gateway!

Any ideas anyone, B_B?

[DNR]

there could be miscommunication due to meaning of terminology used, so I will either help with the understanding or just add to the confusion.

You are dealing with a private IP, not a internet assigned IP.

_Time to get to work__

Query for 1.1.168.192.in-addr.arpa type=255 class=1
168.192.in-addr.arpa SOA (Zone of Authority)
Primary NS: prisoner.iana.org
Responsible person: hostmaster@root-servers.org
serial:2002040800
refresh:1800s (30 minutes)
retry:900s (15 minutes)
expire:604800s (7 days)
minimum-ttl:604800s (7 days)

I assume that you posted the IP you are working on, not a spoof to hide your real target in discussion.

NetRange: 192.168.0.0 - 192.168.255.255
CIDR: 192.168.0.0/16
NetName: IANA-CBLK1
NetHandle: NET-192-168-0-0-1
Parent: NET-192-0-0-0-0
NetType: IANA Special Use
NameServer: BLACKHOLE-1.IANA.ORG
NameServer: BLACKHOLE-2.IANA.ORG
Comment: This block is reserved for special purposes.
Comment: Please see RFC 1918 for additional information.
Comment:
RegDate: 1994-03-15
Updated: 2002-09-16

___Cool server names huh?
___
___Edited from RFC 1918

. Private Address Space

The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private internets:

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

We will refer to the first block as "24-bit block", the second as
"20-bit block", and to the third as "16-bit" block. Note that (in
pre-CIDR notation) the first block is nothing but a single class A
network number, while the second block is a set of 16 contiguous
class B network numbers, and third block is a set of 256 contiguous
class C network numbers.

An enterprise that decides to use IP addresses out of the address
space defined in this document can do so without any coordination
with IANA or an Internet registry. The address space can thus be used
by many enterprises. Addresses within this private address space will
only be unique within the enterprise, or the set of enterprises which
choose to cooperate over this space so they may communicate with each other in their own private internet.

As before, any enterprise that needs globally unique address space is
required to obtain such addresses from an Internet registry. An
enterprise that requests IP addresses for its external connectivity
will _never be assigned addresses from the blocks defined above_.

__
In order to use private address space, an enterprise needs to
determine which hosts do not need to have network layer connectivity
outside the enterprise in the foreseeable future and thus could be
classified as private. Such hosts will use the private address space
defined above. Private hosts can communicate with all other hosts
inside the enterprise, both public and private. However, they cannot
have IP connectivity to any host outside of the enterprise. While not
having external (outside of the enterprise) IP connectivity private
hosts can still have access to external services via mediating
gateways (e.g., application layer gateways).

___
Because private addresses have no global meaning, routing information
about private networks shall not be propagated on inter-enterprise
links, and packets with private source or destination addresses
should not be forwarded across such links. Routers in networks not
using private address space, especially those of Internet service
providers, are expected to be configured to reject (filter out)
routing information about private networks. If such a router receives
such information the rejection shall not be treated as a routing
protocol error.

Indirect references to such addresses should be contained within the
enterprise. Prominent examples of such references are DNS Resource
Records and other information referring to internal private
addresses. In particular, Internet service providers should take
measures to prevent such leakage.

___end rfc 1918__

That might explain the trickery you are getting with trying to tracert the IP, I had the same exact situation, some where in the forum on the wifi insecurity...

DNR

[CommonStray]

It would certainly have to do with the router configuration and the association of your ISP providing your internet service. So when you enter your NAT IP into the tracert program, and push start, it accesses the router and finds it immediatly, you should be getting your ISP back because of its association with your network, you should also mabey find another computer on your network as well, but then thats not all that true either because your other computer(s) on your network are using private IP's as well hence the return of the most definitive IP possibility.

Since your not behind a router, and your getting their default gateway, the program has to send it's "ping/data" somewhere and have it return, so it follows the connection to the ISP and back returning that result, it cant find the private IP because there isnt one.

--this is just a opinionated/theoretical response to your question Mab

[maboroshi]

It all makes sense just wish I could understand it

I then run tracert on 192.168.1.1 with an etheral packet capture in promiscuous mode it returns the ips on the internal network by sending an arp request to each system over each hop

Im still a bit confused Im assumng this is still dealing with this

I just resigned up with this isp after much problems with another

I was playing around with an app that well basically is an arp cache posioning tool that I am writing

Basically I was testing it with ethereal regardless it works thats not the point as I am playing with ethereal I notice heavy arp traffic and I am not running the app I am writing I close everything down and rerun ethereal its returning the same results as that original tracert (quote above)

I hate bringing up old topics expecially since I have no fucking clue what I am talking about

It just seems weird to me that I am recieving any ARP Traffic as I shouldn't be in theory


Any ideas

[bad_brain]

take a look at the ethernet-header of data packets. in this header the hardware-adress of a system is set (besides other informations), this is inevitable because the last step of delivering a data packet is to resolve the IP to the hardware-adress of the NIC.
the pair of "which IP belongs to which hardware-adress" for every connection is stored in the arp-cache of your system, don´t know about Windows but in *nix you can view the arp-tables by arp -a
so, where does the arp-traffic come from? whenever you connect to an "unknown" (means not in the arp-cache) adress ARP is checking for the hardware-adress and enters it in the ethernet-header (same happens if the opposite direction when your hardware-adress is not in the arp-cache of the other box). the arp-cache is not permanent and flushed regularly, so arp-requests are sent pretty often.