Server only for relayed requests, not broadcasts

[glenn.satchell at uniq.com.au]

"ignore booting" or "deny booting" are exactly what you want for that 
subnet, causing the dhcp server to not respond to the requests. The 
difference between the two is that deny will log the requests, while 
ignore will not log. Given that it's a /21 network I would guess there 
will be lots of requests and ignore might be a better chioce.

regards,
-glenn

On 2019-04-25 05:42, Rob Janssen wrote:
> 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:
>> 
>> https://kb.isc.org/docs/aa-00379
> 
> 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 172.22.16.0 netmask 255.255.248.0 {
>>>     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)
> 
> Rob
> 
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users