Solved IP address stolen!

B

balanga

By some process which I'm stiill trying to figure out the IP address (192.168.1.1) of my server was assigned to another host which has caused me all sorts of problems including denial of Internet access from my network.

Fortunately I got around this by hooking up another phone to an old laptop and setting up a USB tether.

The IP address was assigned to another host which I was pxebooting FreeBSD via pxeboot.

After rebooting my server, I'm unable to access the Internet through Time to live exceeded msgs.
 
balanga said:
I'm unable to access the Internet through Time to live exceeded msgs.
Click to expand...
That's likely a routing loop. Each packet has a TTL (typically 64 on Linux/BSD), every routing "hop" subtracts one from the TTL. When the TTL is 0 a "Time to live exceeded" ICMP message is returned.
 
SirDice said:
That's likely a routing loop. Each packet has a TTL (typically 64 on Linux/BSD), every routing "hop" subtracts one from the TTL. When the TTL is 0 a "Time to live exceeded" ICMP message is returned.
Click to expand...
Yes I've had this happen recently and found a solution in Thread 101301, but that hasn't worked this time.
 
You need to provide all information in these threads. The network configuration, clients, etc. Who is doing DHCP, have you set up DHCP correctly? Are you sure your USB connection works. USB "tethering" is not stable for 24/7 operation. Don't make us jump between threads.

Your problem is not TTL but basic network setup.
 
Zare said:
You need to provide all information in these threads. The network configuration, clients, etc. Who is doing DHCP, have you set up DHCP correctly? Are you sure your USB connection works. USB "tethering" is not stable for 24/7 operation. Don't make us jump between threads.
Click to expand...

My USB tethering is very stable and only needs attention when I need to reboot my server.

DHCP is set up correctly. What I can't figure out is how the IP address of this server can be re-assigned to another host.
 
What other host? How many hosts do you have on the network?
Is that network in the broadcast domain or do you have Layer 3 routing such as VPN connection? If it's a normal local network, every host on there should be in the ARP table.

Btw I don't understand your last sentence in full. Do you want to discover and get rid of a host that misconfigures itself with that IP address, or do you want to move the IP address between host?
 
DHCP is set up correctly. What I can't figure out is how the IP address of this server can be re-assigned to another host.
Click to expand...

The only reason another host would get 192.168.1.1 is if the DHCP scope contains that address and isn't checking before issuing, it's been manually set on another device, or possibly a device had reset to defaults and that is its default address.

Either way, your IP address has not been *stolen* and this is a basic network management issue.
 
I have three, sometimes four hosts on my network.

The problem occurred when I pxebooted one of my systems and it loaded pxeboot and proceeded to boot FreeBSD disklessly. In the process the IP address 192.168.1.1 was assigned. How that happend I don't yet understand, but I guess it used the /etc/rc.conf of the dhcp server which sets up a static IP address of 192.168.1.1.

I didn't expect that I could pxe boot FreeBSD so easily.
 
I think 192.168.1.1 is a default address for a lot of things. Almost all cable modems, consumer firewall devices, access points seem to default to this. Almost everything I've used has clear instructions regarding this.

Assigning addresses via DHCP and mixing that static assignment is usually a failure waiting to happen unless you set up clear boundaries and everyone follows them.
Say DHCP hands out 192.168.20.0/24 and static assignments are 192.168.30.0/24.

DHCP server hands out addresses from it's pool if it thinks the IP is free and not bound to a static MAC.
 
mer said:
DHCP server hands out addresses from it's pool if it thinks the IP is free and not bound to a static MAC.
Click to expand...

I don't think that it was 'handed out', I think the diskless client was booting up using the configuration of the server,
ie as a stolen identity, if you understand what I'm getting at.
 
I think it's more accurate to say that the diskless client was booting up with the configuration handed to it by the pxeboot server; if that configuration has a hardcoded address of 192.168.1.1 then the diskless client did as it was told. An answer would be to modify the configuration on the pxeboot server to not have the hardcoded address.
 
I am not aware of any specific configuration for a diskless client. I haven't configured anything myself specifically to enable booting disklessly I simply added this to my pxelinux.cfg/default:-

Code: 
label freebsd
  menu label FreeBSD LiveFS
  pxe images/freebsd/boot/pxeboot
 
But that causes a freebsd image to get loaded to the diskless client, no? I'm guessing the contents of that image are where the IP is coming from
 
balanga said:
I don't think that it was 'handed out', I think the diskless client was booting up using the configuration of the server,
ie as a stolen identity, if you understand what I'm getting at.
Click to expand...

No. A "stolen identity" on the local network implies intentional ARP cache poisoning. Think of a man in the middle attack where a host impersonates the gateway.

You have a misconfiguration. The PXE client needs to use the DHCP address handed over.
 
And again, apart of discussing what might or not might be going on, how about you paste some of your configuration files, rc.conf, dhcpd.conf, and so on. Also write down exactly what is the PXE image you're booting over the network that "steals the IP".
 
The PXE image is

/boot/pxeboot

It is invoked by this entry in pxelinux.cfg/default:-

Code: 
label freebsd
  menu label FreeBSD LiveFS
  pxe images/freebsd/boot/pxeboot

My DHCP server wo rks normally and other utilities booted by my PXE server work normally.
diskless() may point me in the correct direction.

The problem is not related to the configuration files you mention.
 
You must log in or register to reply here.
Back
Top