subnet, causing the dhcp server to not respond to the requests. The
ignore will not log. Given that it's a /21 network I would guess there
> 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
>
[hidden email]
>
https://lists.isc.org/mailman/listinfo/dhcp-users
Locked
