On 7/3/23 21:14, Mark wrote:
I really do remember, under FreeBSD, I was having a similar "dmesg -a"
output

telling about DHCP's permission denied issue, and finally

I solved it with a pass rule like:

"pass log quick on $ext_if proto udp from any to any port = 67 keep state"

in /usr/local/etc/pf.conf file.

Well unfortunately memories are rather unreliable. Additionally, people
often times come to incorrect conclusions. For starters even if that
rule mattered, you should at least have "out" specified since that rule
is only trying to handle traffic sent to the DHCP server. Two, there
should be a corresponding rule for ingress traffic sent to the DHCP
client. Three, "keep state" is irrelevant since the traffic is sent to
255.255.255.255:67, but the response is sent from a DHCP server or relay
server that most certainly doesn't have the IP 255.255.255.255; thus the
state entry is pointless. It's one thing to rely on the default behavior
(i.e., "keep state"), but to explicitly add that is at the very least
bizarre.

And reading DHCP traffic never makes its way to pf,

surprised me. Perhaps that's valid only on OpenBSD but not on FreeBSD?

Anyways..

It probably surprises many, but it has been that way for a while.
Besides my "proof" that such rules are irrelevant, you can and even
should read more. There was even a recent thread on @misc where someone
inquired why there are DHCP-based rules in rc(8) when such rules don't
matter, and Theo de Raadt explained the historical reason for it.

I also doubt that it's "valid only on OpenBSD but not FreeBSD" despite
what you (mis)remember, but I am not interested enough to spend time
installing FreeBSD just to prove this. I spent a minute searching, and
dhclient(8) 
(https://man.freebsd.org/cgi/man.cgi?query=dhclient&sektion=8&format=html)
explicitly talks about BPF, and this very old thread
(https://lists.freebsd.org/pipermail/freebsd-ipfw/2005-April/001756.html)
is about someone not able to block DHCP traffic with ipfw(8) where the
reason given was "dhcpd uses BPF directly (like tcpdump)". I realize
that thread is very old, concerns dhcpd instead of dhclient, and the
individual uses ipfw instead of pf; but those two references in
addition to your dubious rule are enough for me to maintain my
skepticism.

Reply via email to