[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DHCP Problem, but where



On Sun, Dec 3, 2023 at 9:57 PM jeremy ardley <jeremy.ardley@gmail.com> wrote:
>
>
> On 4/12/23 05:18, Geert Stappers wrote:
> > That triggered me to ask "Has the DHCP server been restarted?"
>
>
> The default behaviour of most dhcp clients when they can't connect to a
> dhcp server is to maintain the settings from any previous lease.
>
> A second default behaviour is for clients to not request new dhcp until
> their existing dhcp lease has expired.
>
> To make sure a new dhcp setting is taken by all clients you need to
>
> -  reconfigure your dhcp server
>
> - restart your dhcp server
>
> - check your dhcp server logs for any problems
>
> - restart your dhcp clients
>
> - check your client dhcp logs to see if the new lease info has been taken.
>
> There can be problems where a client with a specific MAC address
> requests a specific ip address based on a previous lease but the server
> is unwilling or unable to allocate that address to that MAC. This can be
> checked in the server and client logs. It may also require flushing the
> server lease tables and client configs so they can both start out
> completely fresh.

The "restart your dhcp clients" may have a sharp edge. Sometimes the
clients have a touch of resiliency or hardening added so they contact
their original dhcp server, and not a [possibly] rogue server setup by
an unknowing developer or attacker. In the past, you used to have to
reboot Microsoft clients to get them to use the new dhcp server. I
don't know Linux behavior.

But if the problem is, dhcp clients are using the old dhcp server or
old dhcp lease info, then I would try to reboot a client if the
service restart did not help.

(I saw a similar attack happen as an undergrad at the University of
Maryland. Someone in the CS department setup a Linux server with
Kerberos running. Workstations got answers from the rogue server and
got [useless] tickets granted, and the [useless] tickets could not be
used for authenticating to other services on the UMBC network. It was
an intermittent problem, and it took a couple of weeks to straighten
it out).

Jeff


Reply to: