[Dnsmasq-discuss] dnsmasq dhcp relay not relaying response from upstream to client

[Geert Stappers]

On Sat, Jun 26, 2021 at 01:26:10PM +0200, Nicolas Cavallari wrote:
> Let's look at the reply from freeradius:
> 
> > (14) Sent code 1026 Id 24307805 from 10.10.254.1:67 to 10.10.253.1:67 length 0
> > (14)   DHCP-Relay-IP-Address = 10.10.253.1
> > (14)   DHCP-Client-Identifier = 0xff2784511b000100012867cc8108002784511b
> > (14)   DHCP-IP-Address-Lease-Time = 7200
> > (14)   DHCP-Client-IP-Address = 255.255.255.255
> 
> This is suspicious. RFC 2131 Table 3 says ciaddr (Client IP Address) should
> be 0.0.0.0 in a DHCPOFFER, and should otherwise mirror the ciaddr sent by
> the client, which, in this case, was 0.0.0.0 too.
> 
> > (14)   DHCP-Your-IP-Address = 10.10.253.3
> > (14)   DHCP-Subnet-Mask = 255.255.255.0
> > (14)   DHCP-Router-Address = 10.10.253.1
> > (14)   DHCP-Domain-Name-Server = 8.8.8.8
> > (14)   DHCP-Message-Type = DHCP-Offer
> > (14)   DHCP-Gateway-IP-Address = 10.10.253.1
> > (14)   DHCP-DHCP-Server-Identifier = 255.255.255.255
> 
> This is HIGHLY suspicious. This is supposed to be the address of the server.

Good observation.

 
> The rules are set in section 4.1 of the RFC, and most notably:
> 
> "a server MUST choose an address as a 'server identifier' that, to the best
> of the server's knowledge, is reachable from the client."
> 
> This is not going to work well in this case.
> 
> > (14)   DHCP-Opcode = Server-Message
> > (14)   DHCP-Hardware-Type = Ethernet
> > (14)   DHCP-Hardware-Address-Length = 6
> > (14)   DHCP-Hop-Count = 1
> > (14)   DHCP-Transaction-Id = 24307805
> > (14)   DHCP-Flags = 0
> 
> The "broadcast" flag is not set. This means that the client supports unicast
> replies, so the relay should unicast the reply to yiaddr using chaddr...
> 
> So what would dnsmasq do with such a response ?
> 
> relay_reply4() would correctly detect that this is a server-to-relay
> response, so is_relay_reply = 1,
> 
> but ciaddr is not zero, and dnsmasq will trust ciaddr over yiaddr (this
> makes perfect sense for a DHCP server, a relay should not see anything with
> ciaddr != 0 anyway). so the destination is set to 255.255.255.255:68, and we
> skip all the destination selection code (the one that looks at the broadcast
> flag), as well as the interface selection code.
> 
> dnsmasq would probably sends the packet to 255.255.255.255:68 without
> telling on which interface it should be sent or which source address should
> be used, because ciaddr is supposed to be a unicast address. What the kernel
> would do in this case is anyone's guess.
> 
> Even if such a message could be forwarded verbatim to the client, it would
> probably confuse it. When a client receives a lease from a DHCP server, it
> will renew it by sending unicast packets directly to the server's "server
> identifier" address, without involving the relay. But here, "server
> identifier" is set to 255.255.255.255...
> 
> On the other hand, the ISC DHCP server/relay/client have probably seen their
> share of nonsensical DHCP implementations, and can probably see through
> freeradius's nonsense packets.

At https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q2/015184.html
is the message that reports "success" with  isc-dhcp-relay.

Currently there is no information if the swap of "dhcp relay" was the
only change.  There _could_ be also change at freeradius DHCP server
configuration.

Senseble thing would be revert the swap, so dnsmasq again as "dhcp relay",
and see if:
 * problem still exists
 * problem can be eliminated by re-configuring the Freeradius DHCP server



Groeten
Geert Stappers
-- 
Silence is hard to parse