Tracking Down A Rogue IP Addresss In Windows

I had to track down a rogue IP today, and so I thought I should record the process.

First off, what happened? I had a user who lost connectivity a few times this morning - a reboot cleared it up for them. After investigating a bit, we found that they were getting a conflicting IP error.

I Checked our DHCP server, and found that, yes, the user did have the lease for that IP, and there were not any other for that IP in the system.

So I excluded that IP, in DHCP, and released and renewed her via IPconfig. She got a new IP and was off an running.

Now, I had to figure out what the "Rogue IP" was. I had visions of shenanigans from staff - like someone bringing in their own wireless router, or setting up some server.

I was able to ping that IP address, so I knew at least it was not just there intermittently.

First I used Radmin Advanced Port Scanner on the IP to try to learn some more about it. Only port 80 (http) showed as being open. So I tried to connect to it with a web browser. No luck.

Since I had pinged the address, I was able to use this command:

arp -a

In windows, arp displays the IP to physical address translation tables. In short, if you use arp with a -a argument, it will show you all the IPs you have touched on your system, with the MAC address.

So, now that I had the MAC, I could attempt to figure out what the device that has this IP is.

At this point I could have used this site to figure out what the device is, or gotten into my switches and figured out which port connected to that IP. But I didn't need to do either of those. I recognized the MAC as belonging to one of our VOIP phones.

Then it was simple for me to go into our VOIP system, and figure which phone it actually was. Our phones have a tendency to get locked up, and stop responding. It turns out one of our phones had done that, was still using its IP, but had not responded to our DHCP server in a timely fashion, and the lease had been recycled, and the IP given to the user who had the original problem.

Resetting the phone cleared its issue, and now all is well. If you ever follow this procedure, don't forget to un-exclude the problem IP in DHCP when you get it all resolved.