Bug #10666
closed
DHCP Server sends NAK messages for declined offers
0%
Description
Test Scenario:
pfSense is configured to host two DHCP servers on the same network segment. Namely, configure two interfaces on the same LAN segment (they can have disjoint addresses in different subnets, just need to be on the same broadcast domain, e.g. same switch, or same VLAN), then on each interface set up a DHCP server, we'll call them DHCP_1 and DHCP_2. Configure DHCP_1 with at least one entry in the MAC Allow field, so that your test client won't receive an offer from DHCP_1.
Let your DHCP client start the DISCOVERY process. DHCP_1 will see the discovery, and not send an offer; DHCP_2 will see the discovery, and will send an offer.
The test client will answer accepting DHCP_2 offer, namely sending a broadcast REQUEST packet, with DHCP_2 server identifier as selected server. According to RFC 2131, Sec 3.1.4, this is implicit decline for any other DHCP server (in fact, DHCP_1 didn't even make an offer).
At this point, the reported bug kicks in: DHCP_1 will parse the client REQUEST packet as if it was addressed to DHCP_1, and will answer with a NAK message, which should have never been sent.
Note that many clients still operate correctly: they will ignore DHCP_1's NAK message (it comes from a server they didn't select), and when DHCP_2's ACK message will arrive, they'll get the IP address configured. However, some clients follows RFC 2131, Sec 3.1.5 strictly: "If the client receives a DHCPNAK message, the client restarts the configuration process." Some clients don't check the source of the NAK message, and hence enter into a DHCP loop.
Proposed fix: in pfSense DHCP server, when a REQUEST message is parsed, it is considered a decline if it is for a different DHCP server identifier, hence no action is taken and no NAK message is sent.
Updated by Jim Pingle over 4 years ago
- Category set to DHCP (IPv4)
- Status changed from New to Rejected
- Affected Version deleted (
2.4.5-p1) - Affected Architecture All added
- Affected Architecture deleted (
amd64)
There is no bug. That is not a valid configuration. You can't have two DHCP servers in one segment.
Updated by Alfredo Pironti over 4 years ago
Hi Jim,
Looking at RFC 2131, this actually looks like a legit configuration. Various excerpts of the RFC seem to encompass this scenario. See below for your quickest reference:
- Sec 1.6, bullet #5:
"A DHCP client must be prepared to receive multiple responses
to a request for configuration parameters. Some installations
may include multiple, overlapping DHCP servers to enhance
reliability and increase performance."
- Sec 3.1.2: "Each server may respond with a DHCPOFFER message [...]"
- Sec 3.1.3:
"The client receives one or more DHCPOFFER messages from one or more
servers. [...] The client chooses one server [...].
The client broadcasts a DHCPREQUEST message
that MUST include the 'server identifier' option to indicate which
server it has selected [...]"
- Sec 3.1.4:
"The servers receive the DHCPREQUEST broadcast from the client.
Those servers not selected by the DHCPREQUEST message use the
message as notification that the client has declined that server's
offer. The server selected in the DHCPREQUEST message commits the
binding for the client to persistent storage and responds with a
DHCPACK message [...]
If the selected server is unable to satisfy the DHCPREQUEST message
[...], the
server SHOULD respond with a DHCPNAK message."
Crucially notice how NAK should be sent by the selected server (in case the request cannot be satisfied), not by a server that was not selected. This is exactly the bug I'm reporting. Hope this clarifies!
Updated by Jim Pingle over 4 years ago
We do not control the DHCP daemon on that level, that's up to the ISC DHCP daemon. Take it up with them, but I doubt they would care much about two non-HA servers on the same L2.
Either way, having two non-HA DHCP servers on the same L2 has never been a supported or valid configuration on pfSense, or on many other platforms, and not something we intend on attempting to support.
Updated by Alfredo Pironti over 4 years ago
Hi Jim,
Thanks for your feedback. For future reference, by reading the ISC DHCP manual I found this configuration is fully supported using the shared-network statement [[https://kb.isc.org/docs/isc-dhcp-41-manual-pages-dhcpdconf#reference-declarations]].
Shame it won't make it to pfSense; this is a common scenario for anyone using one pfSense instance as a DHCP relay; the other pfSense instance receives DHCP requests from multiple networks on one interface. As a workaround, I'm patching the generated conf file, and restarting the daemon, taking inspiration by [[https://happy-coder.com/2014/06/27/pfsense-custom-dhcpd-configuration/]]. Hope this helps others in the same situation.