Server only for relayed requests, not broadcasts

Rob Janssen rob at
Wed Apr 24 19:42:45 UTC 2019

Peter Rathlev wrote:
> On Wed, 2019-04-24 at 10:40 +0200, Rob Janssen wrote:
>> The forwarded DHCP requests are sent to the machine's IP on ens224
>> (the router knows to forward them to this machine),
>> however it appears that it is impossible to listen on an interface
>> only for handling forwarded requests.  Is that true?
> By default this is true. ISC DHCPd uses raw sockets unless compiled
> otherwise. For it to receive packets on an interface, even if they're
> actually destined to an address on another interface, it needs to
> listen on the interface. And since it's a raw socket the server will
> see local broadcasts.
> You might try looking into compiling a version yourself with the
> configure option "--enable-use-sockets". This will make the server not
> use raw sockets but regular BSD sockets. And this again will make it
> behave much more like you expect.
> Take a look at this KB article:

Unfortunately it looks like this is a global compile directive, while in my use case I need it to
behave differently on the different interfaces: on ens192 I would like it to receive on a normal
UDP socket, but on ens224 I require the "raw socket" functionality as the clients are local there.

I fact I do not really mind that it uses a raw socket (although it of course wastes CPU), but I
would like to see a configuration directive to make dhcpd ignore broadcasts on an interface.
(not only "not reply" but also "don't bother to log anything")

It does not appear to be such an unusual use case.  Especially in a network that uses lots of
different VLANs to separate management and operational networks.

My use case is for the management interface of wireless access points in a company with
different locations, where the management server is at a single location and serves the local
devices directly on a management VLAN specific to that purpose, while devices at other locations
are on a similar VLAN locally, but this is routed towards the central location.
I have considered setting up an L2 or L3 tunnel between the management networks, but it seems
overly complex to work around such an issue (there are L3 firewall rules that prohibit traffic into-
and out of the management network towards other networks).

>> So I have included a dummy section for ens192 like this:
>> subnet netmask {
>>     deny unknown-clients;
>>     deny client-updates;
>>     not authoritative;
>> }
> [...]
>> Even with this config, the server is logging requests that it simply
>> should not see, like:
> Could you add "ignore booting" to that subnet declaration? It's valid
> syntax though I'm not entirely sure does what you want.
Ok added that and see what happens (tomorrow when the clients on that network start again).
(It is accepted without warning or error)

>> I even tried an nftables filter:
> [...]
>> This catches the "wrong" packets, counter increases, but DHCPD still
>> sees them.
> This is again because of the raw sockets. Just like "tcpdump" will
> actually see packets dropped by a filter, DHCPd will also.

Indeed, it appears that the "ingress" filter is not as useful as I thought it would be.
(I hoped that it would also filter the traffic that tcpdump sees, but it doesn't)


More information about the dhcp-users mailing list