0

I have a weird issue on my local network which prevents some clients, sometimes acquiring an ip address from the real dhcp-server (x.x.x.3). The dhcp-server is a CentOS VM running isc-dhcp-server for ipv4. The router from my ISP, a Sagemcom has the dhcp-server (x.x.x.1) disabled.

However, when a client is connected directly to the Sagemcom router, I sometimes see a response like this:

The server offers address x.x.x.181 from x.x.x.3
NACK: Requested address not available from x.x.x.1

(not exactly like that...) So, why is the router giving a NACK, while it's supposed to be turned off ? What role exactly does the directive 'authoritive' from the dhcpd.conf play here ?

So my most important question, how can I troubleshoot this ?

If I run a nmap --script broadcast-dhcp-discover when my own dhcp-server is inactive, I do not receive a reply.

Diamond
  • 8,791
  • 3
  • 22
  • 37
oneindelijk
  • 159
  • 8
  • Can you check, if you have any dhcp relay configured somewhere which is pointing to Sagemcom router? – Diamond Jul 19 '18 at 15:03
  • How have you disabled the DHCP server on the router? Are you sure the disabling works correctly? – Tero Kilkanen Jul 20 '18 at 06:24
  • @TeroKilkanen The only option is a switch in the webinterface of the router, so I'm not sure at all it is switched off correctly. However, I get no reply from the nmap dhcp-discover script if I turn of the authorative dhcp server – oneindelijk Jul 20 '18 at 10:44

2 Answers2

2

What role exactly does the directive 'authoritive' from the dhcpd.conf play here?

From the dhcpd manual:

The DHCP server will normally assume that the configuration information about a given network segment is not known to be correct and is not authoritative. This is so that if a naive user installs a DHCP server not fully understanding how to configure it, it does not send spurious DHCPNAK messages to clients that have obtained addresses from a legitimate DHCP server on the network.

So that means that the dhcp server will send a NACK if it gets a request for an address it doesn't know about. In your case, it is the other dhcp server that sends the NACK, so the 'authoritive' on your server doesn't matter in this case, but it would if a client would request an address that belongs to the other dhcp server.

You can run tcpdump with the -e option to see which ethernet host sends the NACK. It could either be the router or a proxy that was configured to forward to the router. Depending on the configuration of a potential proxy, it might answer with NACK if it doesn't receive an answer from the dhcp server.

RalfFriedl
  • 3,008
  • 4
  • 12
  • 17
1

Possibly you have a dhcp relay/dhcp helper configured somewhere in the network, which is pointing to the "disabled" dhcp server. The request will contain the ip address of the relaying device and when this is not matching with the dhcp subnet then a NACK will be issued.The details you can find out by doing some packet tracing.

Ples see here: https://documentation.meraki.com/zGeneral_Administration/Tools_and_Troubleshooting/DHCP_NAK

A DHCP NAK is a negative acknowledgment from the DHCP server. The server will send a DHCP NAK in the following scenarios:

  • Requested address from possibly the same subnet but not in the address pool of the server. This can be the failover scenario in
    which 2 DHCP servers are serving the same subnet so that when one
    goes down, the other should not NAK to clients which got an IP from
    the first server.

  • Requested address is on a different subnet.

  • Requested address is already in use by another client.

To your other questions:

So, why is the router giving a NACK, while it's supposed to be turned off ? What role exactly does the directive 'authoritive' from the dhcpd.conf play here ?

It seems the dhcp server is not really turned off.

Quote from https://linux.die.net/man/5/dhcpd.conf :

The authoritative statement

authoritative;

not authoritative;

The DHCP server will normally assume that the configuration information about a given network segment is not known to be correct and is not authoritative. This is so that if a naive user installs a DHCP server not fully understanding how to configure it, it does not send spurious DHCPNAK messages to clients that have obtained addresses from a legitimate DHCP server on the network.

Network administrators setting up authoritative DHCP servers for their networks should always write authoritative; at the top of their configuration file to indicate that the DHCP server should send DHCPNAK messages to misconfigured clients. If this is not done, clients will be unable to get a correct IP address after changing subnets until their old lease has expired, which could take quite a long time.

Usually, writing authoritative; at the top level of the file should be sufficient. However, if a DHCP server is to be set up so that it is aware of some networks for which it is authoritative and some networks for which it is not, it may be more appropriate to declare authority on a per-network-segment basis.

Note that the most specific scope for which the concept of authority makes any sense is the physical network segment - either a shared-network statement or a subnet statement that is not contained within a shared-network statement. It is not meaningful to specify that the server is authoritative for some subnets within a shared network, but not authoritative for others, nor is it meaningful to specify that the server is authoritative for some host declarations and not others.

So my most important question, how can I troubleshoot this ?

Answer is packet tracing. https://www-01.ibm.com/support/docview.wss?uid=swg21175744

Diamond
  • 8,791
  • 3
  • 22
  • 37
  • I haven't had a chance yet to figure this out, but the relay angle is something I should look into, although my uncle was trying to hook up a Chromecast device to the network while I wasn't home, so I told him to turn of the router, just to allow the device to get an ip address and then turn it back on again (which worked). This makes a relay on the network less likely, does it not ? Unless the router is relaying to itself... The router has other problems too, such as getting pretty hot (the cover is around 50-60 degrees), but it's already the 3rd replacement... – oneindelijk Aug 29 '18 at 02:11