[Dnsmasq-discuss] dnsmasq and dhcp relaying

Jon Nelson jnelson+dnsmasq at jamponi.net
Thu Oct 22 16:29:08 BST 2009

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.

>> 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.

> If you don't like dhcrelay, you could look at
> http://thekelleys.org.uk/dhcp-helper/ as an alternative.

I will!


More information about the Dnsmasq-discuss mailing list