Re: Unexpected pf behavior for DHCP traffic?

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?

Best Regards


On 7/29/21 11:37 PM, Theo de Raadt wrote:
> dhcpleased (and a few other daemons) use bpf, thus see raw packets
> from the wire before pf can block them. Most daemons of this type
> also use bpf to send packets, and pf doesn't see these either.
>
> This behaviour is intentional, and useful.
>
> beebeetles@posteo.de wrote:
>
>> Hi all,
>>
>> I'm running OpenBSD 6.9 as a home router, and observed some behavior of
>> pf that I can't really make sense of.
>>
>> The router runs dhcpleased to obtain its IP address from the ISP, and
>> I have
>> the following pf rules (only the relevant ones are shown):
>>
>> block drop all
>> pass out on $ext_if inet from ($ext_if) to ! <ipv4_reserved>
>> block drop in log (all) on $ext_if inet proto udp from port 67 to port
>> 68
>> pass in on $ext_if inet proto udp from port 67 to 255.255.255.255 port
>> 68
>>
>> (I need to mention here that after digging into some old discussions
>> on the
>> mailing list, I realize that the last two rules are unnecessary
>> because DHCP
>> traffic is supposedly processed by dhcpleased though bpf regardless of
>> pf's
>> decision, but my question is something else)
>>
>> With tcpdump on the external interface, I see packets similar to the
>> following
>> for lease renewal:
>>
>> {timestamp} {my_ip}.68 > {ip1}.67: xid:0xfe51c9a3 [|bootp]
>> {timestamp} {ip2}.67 > {my_ip}.68: xid:0xfe51c9a3 Y:{my_ip} G:{ip1}
>> [|bootp]
>>
>> Note that DHCP renew request is sent to {ip1}, but the DHCP
>> acknowledgment
>> is from {ip2}, so I guess {ip1} is a DHCP relay?
>>
>> The problems is, with my existing pf rules I expect the second packet
>> to be
>> blocked and logged to pflog0, but in reality, a tcpdump on pflog0
>> shows that no
>> packets are being blocked:
>> tcpdump -l -n -i pflog0
>>
>> Why is the second packet not blocked by pf when its source ip address
>> {ip2} is
>> supposedly not in the state table?
>>
>> I would greatly appreciate any help on this.
>>
>> Best Regards