Hi again, thanks for your detailed and very informative reply, Zack. Much appreciated!
I wanted to re-try the fact (memories), on FreeBSD 13.2-RELEASE-p1; I removed the pass line from my pf.conf; "pass log quick on $ext_if proto udp from any to any port = 67" reloaded PF, then dmesg -a showed; Jul 4 04:59:09 myhost dhclient[18366]: send_packet: Permission denied Jul 4 04:59:33 myhost syslogd: last message repeated 3 times Jul 4 05:01:43 myhost syslogd: last message repeated 4 times Jul 4 05:11:29 myhost syslogd: last message repeated 18 times Jul 4 05:20:11 myhost syslogd: last message repeated 10 times I then, enabled the line again: "pass log quick on $ext_if proto udp from any to any port = 67" Restarted pf. the "dhclient: send_packet: Permission denied" messages were gone, disappeared from "dmesg -a" output, and it wasn't produced anymore. I tried this, again and again. Obviously PF blocks something. Just my two cents.. Subject: Re: dhcpleased[59824]: sendto: Permission denied From: Zack Newman <zack () philomathiclife ! com> Date: 2023-07-04 15:41:31 Message-ID: a1d467d7-6a63-00dd-72c3-e9bd8dd7e1a8 () philomathiclife ! com 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.