14

I have a network containing 20 clients. I assigned IP range 10.0.0.1 to 10.0.0.20 to them. When I do an IP scanning I see someone using 10.0.0.131 in VMware. How can I find out which IP is this IP bridged with? i.e How can I find out which system has 2 IP? (i.e the other IP of this system)

Update:

My system IP in the network is 10.0.0.81:

enter image description here

Output of the IP scanner show someone using 10.0.0.131 in VMware:

enter image description here

And the result of tracert command show nothing between us:

C:\Users>tracert -j 10.0.0.131 10.0.0.81

Tracing route to ghasemi3.it.com [10.0.0.81]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  ghasemi3.it.com [10.0.0.81]

Trace complete.
C:\Users>
Improve this question
4
  • 1
    Is the switch a dumb switch, or is it managed?
    – Kinnectus
    Jun 1, 2015 at 9:35
  • @BigChris I don't know what do you mean by dump. But it is not managed. :)
    – User1-Sp
    Jun 1, 2015 at 9:47
  • 1
    A dumb network switch is one that doesn't have any ability for you to manage or interrogate the switch device itself - i.e to be able to find which port the MAC address of the machine you're trying to find is connected to. Dumb switches don't have an additional "management" port.
    – Kinnectus
    Jun 1, 2015 at 9:56
  • 2
    Failing all else, since it's such a small network, you could locate it by trial and error: pull out the wires one at a time until you find the one that cuts your connection to the address in question.
    – Harry Johnston
    Jun 2, 2015 at 0:23

7 Answers 7

Reset to default
13

I cannot provide a global solution to your problem, just a partial one. You can add this to the switch technique to widen your range of opportunities.

If the user running the VM is connected to your LAN via wifi, then you can identify him/her by means of a traceroute. The reason is that you showed us that the VM has an IP on your LAN network, hence it is in a bridged configuration. For technical reasons, wifi connections cannot be bridged, hence all hypervisors use a neat trick instead of a real bridge configuration: they employ proxy_arp, see for instance this Bodhi Zazen's blog entry for an explanation of how this works, for KVM, and this page for VMWare.

Since there is a pc replying to ARP queries in the VM's stead, traceroute will identify the node before the VM. For instance, this is the output of my traceroute from another pc on my LAN:

My traceroute  [v0.85]
asusdb (0.0.0.0)                                                                                               Mon Jun  1 11:45:03 2015
                        Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                                           Packets               Pings
 Host                                                                                       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. rasal.z.lan                                                                           0.0%     1    6.0   6.0   6.0   6.0   0.0
  2. FB.z.lan

rasal is the host machine, FB is the guest, I am issuing this from a third pc (asusdb).

In Windows, the proper command is 

 tracert 10.0.0.131

On Linux, you can do the same with the very convenient utility mtr:

 mtr 10.0.0.131

This complements, rather than supersede, the switch technique. If your traceroute shows that there are no intermediate hops between your pc and the VM, then at least you will know that you can rule out all LAN pcs connected via wifi, restricting your range of possibilities, and making the switch technique an effective possibility, if you have a managed switch or you are willing to unplug the cables in the switch one by one.

Alternatively, you may fake a technical problem and disconnect all ethernet connections, forcing your users to use wifi, until your culprit takes the bait.

Improve this answer
8
  • 3
    If the VM is bridged there are no IP hops between source and destination. The tools tracert and mtr are very good to make a trace of IP routing paths, but unable to discover bridges and switches that work at level 2.
    – jcbermu
    Jun 1, 2015 at 9:34
  • You're right. Please include the explanation on your answer so I can upvote you again
    – jcbermu
    Jun 1, 2015 at 9:46
  • May I ask you to check the update section in my question. I think your solution doesn't worked for me. Am I right? (The IP numbers in real are a little different with the values that I mentioned in the question already- I changed 123 to the real value : 131. May I ask you to correct it also?)
    – User1-Sp
    Jun 1, 2015 at 10:18
  • 3
    @MariusMatutiae If the VM software were actually using proxy ARP, the MAC address as shown in the screenshot wouldn’t have a VMware OUI.
    – Daniel B
    Jun 1, 2015 at 11:52
  • 2
    Certainly. That’s still not what I’m talking about, though. I’ll say it again very clearly: A VMware OUI MAC is visible. This clearly implicates that proxy ARP is not used. VMware uses proxy ARP only when needed: On wireless connections.
    – Daniel B
    Jun 1, 2015 at 12:46
10

I'm assuming the 20 clients are connected to a switch:

Every switch mantains a table of every known MAC address on the table, and the table is in a format like this:

    Port               Address
     1              fa:23:65:XX:XX:XX:XX
     2              87:4a:12:d2:xx:XX:xx

Where Port is the physical port on the switch and Address is the MAC address detected on the port.

You have to check on the switch console a port that registers more than one MAC address, and now you know the switch port where the VM host is connected.

Just to be sure:

From a Windows equipment ping 10.0.0.123 and then issue arp -a.

Check that the MAC address corresponding to 10.0.0.123 is the same that you detected on the switch table.

Improve this answer
0
4

I did things like this sometimes in the past. What confuses me: you are using your tools in VMware? So I assume 10.0.0.0/24 is your physical network and not a virtual one? You should also know that some tools may display something weird because of the extra network layer (the vmware virtual network).

First thing you can do for analyzing:

  • Ping the host and then do arp -a (may be slightly wrong, I'm using Linux). Look for the MAC address and use an online service like http://aruljohn.com/mac.pl to lookup the first 3 pairs of the address. You will see the manufacturer of the device.

  • In the arp list, you can also check if the same MAC address is used by two different IPs. This would mean the device has two of them.

  • Also the ping time is interesting. Compare it with known PCs and maybe a printer in your network. PCs are normally faster in answering than printers of internet routers. Unfortunately, Windows' time precision is not very good.

  • Last but not least, I recommend running nmap -A 10.0.0.131 or nmap -A 10.0.0.0/24 which reveals more information about a specific host or the full network. (Thx to pabouk)

Improve this answer
4
  • 1
    From the three answers this is the best one of what can be done directly from any computer on the L2 segment. Additionally I would run a really :) advanced scan to reveal additional information about the computers - using for example nmap: nmap -A 10.0.0.131 or nmap -A 10.0.0.0/24. This way you can discover for example the OS, computer name, running services, their versions etc. --- This could be really helpful if you do not find two IP addresses with the same MAC.
    – pabouk - Ukraine stay strong
    Jun 1, 2015 at 17:43
  • Pinging the host then doing arp -a will return the MAC address of the VM, which we already know;looking up the the first 3 octets returns the manufacturer VMWare, which we already know. Comparing ping times yields nothing, since it depends on traffic, and on physical proximity. Occasionally, it may be a good idea to try one's own answer before presenting to a general audience.
    – MariusMatutiae
    Jun 1, 2015 at 21:00
  • @MariusMatutiae I explicitly wrote that i assume your host is in the network. I didn't setup a VMware VM just to find it afterwards. In your case you are looking for a virtual machine on your own host. This shouldn't be too complicated to find ;-)
    – Daniel Alder
    Jun 2, 2015 at 7:25
  • @MariusMatutiae Just an extra: Try running ping and arp -a on the host instead of the VM and tell me if you see a difference. You see the reason for this in the first paragraph of my answer.
    – Daniel Alder
    Jun 2, 2015 at 7:39
2

Tracking down an unknown machine on an unmanaged network is difficult. I've been tasked with this a few times, and in order of preference, this is how I deal with them:

  1. Attempt to browse the server (if you are concerned about security if it's some sort of honeypot, do it from a throwaway VM). You never know - browsing to that machine in a web browser may very well just reveal its PC name, or its purpose. If it's got a self-signed SSL certificate then that will often leak the internal server name as well.

    If it's not running a web service, and you think it's a Windows PC, try connecting to its administrative shares (e.g. \\example\c$) - you might get lucky with guessing an administrator username. Or if you think it's a Windows Server (or a Windows Professional edition) then try remote desktopping into it.

    Once you're in some way, then you can search for information about the machine's purpose, and thus who may have created it and put it on the network in the first place. Then track them down.

    Some of this information (like PC name, and that it's a Windows box) have already been revealed by your scanner, so there may not be much to learn here for you.

  2. Look at the switch's ARP table. This will give you a mapping between that MAC address and a physical port and VLAN. This is not possible in your situation as you do not have a managed switch.

  3. Compare the MAC address for that IP address to your local ARP table. Maybe there is a duplicate MAC address in there, which indicates two IP addresses on the same physical interface. If the other IP address is known, then there's your culprit.

  4. Start a ping to the machine. If it responds to ping, unplug cables from the switch, one by one, until the ping fails. That last cable you unplugged is leading to your culprit.

Improve this answer
1
  • That last tip is probably the ultimate (and only) universal solution for unmanaged networks.
    – Daniel B
    Jun 2, 2015 at 13:39
1

Also not a full solution - indeed there may not be a full solution to your question depending on your setup, and ignoring unplugging devices - but could help.

If you get the devices MAC address (ie look at the arp table), the first 3 octets of the address can often tell you something about the address - just punch them into a mac lookup finder like http://www.coffer.com/mac_find/

Programs like NMAP provide fingerprint detection which can also aid in working out the device in question by looking at the way its TCP stack is built. Again, not fullproof but it can often help.

Another way (assuming you are on a wired only network) might be to flood the inappropriate address with traffic and look for which port on the switch goes ballistic - then trace the cable. On a WIFI network things are a lot harder (you might be able to force the device onto a fake access point, then start moving it and looking how the signal behaves to triangulate the device - but I've not tried something like this).

Improve this answer
0

Some of the methods for connecting a printer to a local network give the printer an IP address outside the range likely to be used by computers on the network, so you might want to check for such a printer.

Improve this answer
1
  • The VMware OUI in the MAC address as well as the PC name and IIS listening clearly indicate this is not a printer.
    – Daniel B
    May 23, 2016 at 21:26
0

You have only about 20 clients. You are using a dump switch.

I read this as "you have precisely one cheap switch" and all 20 PCs are connected to this single device. Each active port on the switch usually has one more or more LEDs to indicate link speed and activity.

The last gives us an easy solution. Create lots of traffic for your VM and looks which port lights up. Depending on your OS you might want to use one or more cmd prompts with ping -t 10.0.0.81. Of on a unix like system you could use ping -f 10.0.0.81 to flood that IP. (Warning, flood ping is going max speed that you PC can handle. This will slow down your entire network while it is running. It will also make the LED burn permanentnly.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .