dhclient fails and breaks networking (uses a weird ip/subnet mask settings)
Yesterday the router on the network went bad and seemed to start giving out IP addresses on 192.168.100.x IP addresses, it was unreachable, after a while it seemed to resolve itself and was accessible again through new connections, it had permanently leased 192.168.100.x to the machines on the network. There are Windows machines and a Debian (9) machine on the network. I configured the Windows machines to use specific IP addresses, renewed the ipconfig and they continued to work without issue. The Debian machine (which is connected to remotely) has no connection anymore.
The network was originally serving IP addresses on 192.168.178.x, subnet 255.255.255.0. Which it is doing so again.
I setup the port forwarding rules again after factory resetting the router and my box was accessible again remotely via SSH. The machine acts as server for the office and is managed remotely by me.
Weirdly though, the machine has no connection itself even though my SSH connection works fine and if I run sudo dhclient -v the machine then drops my connection and reverts to 192.168.100.19 on subnet 255.255.255.255. Only restarting the machine seems to make it accessible again, but it no longer has an internet connection to the applications it is running.
I have some pictures of some things I have tried to no avail.
/etc/network/interfaces:
After the dhclient command is ran:
Before it is ran I can connect and it shows this with ip addr:
Tried backing up then removing the leases file:
Tried deleting the default IP route:
Sorry for the potato pictures but I'm doing this via someone who is at the physical location, I myself am working remotely. I'm at a loss, and short of walking through reinstalling the operating system and praying I'm not sure what to do.
DHCPOFFER of 192.168.100.19 from 192.168.100.1
means DHCP server at 192.168.100.1 offered an address. The client agreed and expected DHCPACK (acknowledgment) but got:
DHCPNAK from 192.168.178.1
This means DHCP server at 192.168.178.1 objected (probably because it could only agree to 192.168.178.zzz). After a while there was another try:
DHCPOFFER of 192.168.100.19 from 192.168.100.1
but now DHCP server at 192.168.100.1 was faster than 192.168.178.1:
DHCPACK of 192.168.100.19 from 192.168.100.1
The client now "thinks" everything is OK since some server acknowledged the address.
Conclusion: there are two DHCP servers, 192.168.100.1 and 192.168.178.1, they disturb each other. You need to investigate what the extra server is and make it stop. The term is "rogue DHCP". Compare this answer of mine.