I work for an MSP and recently ran into a confusing IP conflict at a small restaurant. Their credit card system uses a computer configured with the static address 192.168.x.140. The DHCP scope also included addresses from .100 through .150, but the server's address had never been excluded or reserved because the network was poorly documented.
Eventually the credit card system stopped working. We discovered that another device had leased .140, so we deleted that lease, expanded the DHCP scope, and created a reservation for the credit card computer. We then tried disconnecting the network switches to force the unknown device to obtain a different address. That caused the restaurant's network-controlled lighting system to go offline, but the mystery device still appeared to be using .140.
After tracing the device, we found that it was a Samsung Android-based smart TV connected over Wi-Fi. Turning the TV off brought the credit card system back online. Turning the TV on again caused the conflict to return. The TV was supposedly configured for DHCP, yet it continued using .140 until we manually assigned it a different address.
How could the TV keep using an address that had been deleted from the DHCP server, especially after the DHCP scope was changed? Could it have been holding an unexpired lease, using a separate wireless DHCP service, or simply retaining the address locally? What would be the safest way to handle this kind of problem in the future?
4 Answers
The TV probably was not bypassing DHCP. A DHCP lease is valid for a period of time, and deleting the lease from the server does not immediately tell the client to stop using the address. The TV could still believe it had a valid lease for .140 and continue using it until renewal or expiration. Many TVs also remain partially connected when you press the power button, so turning them off with the remote may not release the network interface at all.
The IP conflict happened because a static address was placed inside the DHCP pool. The proper fix is to reserve .140 for the credit card server and exclude it from the general pool, or move the server to a static address outside the scope. The TV should also receive its own reservation or a non-overlapping address.
A DHCP reservation is not exactly the same as configuring a manual static address on the client. The clean approach is to reserve the address on the DHCP server and keep the device set to DHCP. If a device must use a manual static configuration, choose an address outside every DHCP scope and document it. Also, an old Windows Server 2008 DHCP system and undocumented switches or Wi-Fi infrastructure should be treated as an urgent modernization and documentation problem, not just a one-off IP conflict.
For future incidents, first identify the device by checking the switch MAC table, wireless-controller client list, DHCP leases, and ARP tables rather than unplugging network equipment blindly. A network scan can help too, but it will not always identify a sleeping or poorly behaved IoT device. Disconnecting switches can take down unrelated systems, as the lighting controller demonstrated.
The bigger issue is the network design. Payment systems, smart TVs, phones, printers, and building-control equipment should not all share one flat network. Put the card-processing systems on a dedicated VLAN with tightly controlled firewall rules, and place TVs and other IoT devices on a separate restricted network. That would prevent a consumer device from creating this kind of conflict and reduce the security and compliance risk.
Whether the payment terminals are using a compliant point-to-point encryption arrangement or not, having an intermediary server mixed in with random consumer devices deserves a proper PCI review.
Deleting a lease on the DHCP server only removes the server's record. It does not revoke the lease already held by the client. A full power removal or waiting for the lease to expire would normally force the TV to start over.