Friday, July 30, 2021

Re: Unexpected pf behavior for DHCP traffic?

On Fri, Jul 30, 2021 at 04:59:03AM +0000, beebeetles@posteo.de wrote:
> Thanks Theo for the answer!
>
> I'm still having difficulty wrapping my head around it.
>
> I have two packets: DHCPREQUEST and DHCPACK
> {timestamp} {my_ip}.68 > {ip1}.67: xid:0xfe51c9a3 [|bootp]
> {timestamp} {ip2}.67 > {my_ip}.68: xid:0xfe51c9a3 Y:{my_ip} G:{ip1}[|bootp]
>
> I get that tcpdump taps to bpf so it can see both packets.
>
> And my understanding of your answer is that pf doesn't see the
> first packet (DHCPREQUEST) since it's being sent using bpf.
>
> The second packet (DHCPACK) -- although dhcpleased has unfiltered
> access to -- is eventually visible to pf, thus will be blocked by
> pf and should show up on the pflog0 interface as per the following
> rule:
>
> > block drop in log (all) on $ext_if inet proto udp \
> > from port 67 to port 68
>
> However, it seems that nothing appears on pflog0 in my case, which
> is what I still can't comprehend.
>
> Am I missing something here?

BPF filters have the ability to drop packets before pf sees them.
dhclient/dhcpleased make use of this feature, and they match any UDP
packets using DHCP-related ports.

No comments:

Post a Comment