[Dnsmasq-discuss] dnsmasq dhcp relay not relaying response from upstream to client
stappers at stappers.nl
Sat Jun 26 14:26:54 UTC 2021
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 = 22.214.171.124
> > (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.
> 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.
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
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
Silence is hard to parse
More information about the Dnsmasq-discuss