[Dnsmasq-discuss] dnsmasq and dhcp relaying

[Simon Kelley]

Jon Nelson wrote:
> On Thu, Oct 22, 2009 at 10:06 AM, Simon Kelley <simon at thekelleys.org.uk> wrote:
>> Jon Nelson wrote:
>>> I've got a setup (working) that looks like this:
>>>
>>> workstations <-> server <-> firewall <-> internet
>>>
>>> firewall is running dnsmasq, server is using dhcrelay
>>> Both firewall and server have iptables-based firewalls
>>>
>>> The setup is working fine, except
>>>
>>> 1. I don't like dhcrelay
>>> 2. I get lots of deny lines in server's firewall logs, *even though
>>> the requests work*.
>>>
>>> Pertinent to item 2, this is what tcpdump shows (on the 'firewall'
>>> interface of 'server').
>>>
>>> - a workstation will broadcast or unicast for an address
>>> - the server receives it on eth1, iptables allows it in, dhcrelay
>>> grabs it, and sends out a new packet on eth0 (the 'firewall' side of
>>> 'server')
>>> - dnsmasq (on 'firewall') receives it (through iptables), generates a
>>> response, and sends it.
>>>
>>> Here's where it gets sticky. dhcrelay receives the request on eth1,
>>> and sends out a request on eth0. The "Relay agent IP address" in the
>>> payload is eth1's IP address. dnsmasq sends the reply *to this
>>> address* (eth1), rather than the address it was received from (eth0).
>>> The dnsmasq payload appears correct, with the "Next server IP address"
>>> and "Relay agent IP address" properly set (eth1).
>>>
>>> This seems to be a bug in dnsmasq - shouldn't it reply using address
>>> that the packet was received on? The payload is correct, the UDP
>>> destination is wrong (it seems to me).
>> The current behaviour is right, according to RFC2131:
>>
>>   If the 'giaddr' field in a DHCP message from a client is non-zero,
>>   the server sends any return messages to the 'DHCP server' port on the
>>   BOOTP relay agent whose address appears in 'giaddr'.
> 
> Is "Relay agent IP address" synonymous with 'giaddr' ? For now, I will
> assume it is.

It is.

> 
>>> That's the reason for the deny lines in the firewall logs, btw -
>>> iptables sees a request go out eth0 and come back in eth0 /destined
>>> for eth1/. Should dhcrelay be putting eth0 into the "Relay agent IP
>>> address" field?
>> No. That would completely break things because the Relay Agent IP address is
>> used to determine which subnet the client is connected to and therefore what
>> IP address to allocate to it. Using the address of eth0 would result in the
>> client getting an address on the network shared by the server and the
>> firewall rather than one on the network shared by the  server and
>> workstations.
> 
> Ah, yes - I see.
> 
> Therefore, what I'm seeing is expected from an RFC point of view - the
> address being requested is in eth1's network, so dhrelay puts eth1
> into giaddr. However, the request goes out eth0.  Despite being
> received on eth0, dnsmasq sends its reply to the address in the
> payload, rather than the address the packet was received from - and it
> is this that confuses me.  Using the normal rules of packet
> forwarding, packets should go back whence they came - DHCP, however,
> uses contents of the payload to determine the reply and in this case
> that conflicts with the actual network layout. This seems like a
> broken-ness of DHCP.

There is quite a lot of that. It does seem to be universal in the DHCP 
spec to ignore the source address and source port of received DHCP packets.

Cheers,

Simon.