So it seems PF was indeed blocking my DHCP stuff. After disabling PF for a
long time, I grabbed this:
"Jul 7 19:13:54 mailsrv dhcpleased[15591]: adding 95.214.xxx.xxx to vio0
(lease from 172.31.1.1)"
from /var/log/daemon file. Noticed; "lease from 172.31.1.1" that's the DHCP
server of my server provider it seems.
(Still weird, as I receive an IP starting like; 95.214.xx from that,
anyways)
AND, I had in my pf.conf file;
martians = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8,
169.254.0.0/16, 192.0.2.0/24, 0.0.0.0/8, 240.0.0.0/4 }"
block drop in quick on $ext_if from $martians to any
block drop out quick on $ext_if from any to $martians
See "172.16.0.0/12" there among the IPs?
Removed that block from the martians and it seems my problem is solved.
Question: for a mail/web server VPS box with a single public IP with only
one NIC, do I really need to block "martians"?
Best wishes.
Mark.
Otto Moerbeek <o...@drijf.net>, 4 Tem 2023 Sal, 21:44 tarihinde şunu yazdı:
> On Mon, Jul 03, 2023 at 10:34:24AM -0600, Zack Newman wrote:
>
> > On 7/3/23 11:25, Mark wrote:
> > > I'm getting (I think once per day) "dhcpleased[59824]: sendto:
> Permission
> > > denied" error message in my daemon and messages log files.
> > >
> > > I think that's happening due to my PF configuration.
> >
> > Certainly could be. If this happens consistently around a particular
> > time, you can "live dangerously" and allow all traffic temporarily to
> > see if the issue is resolved. More safely, use tcpdump(8) to see if you
> > can find the problem.
> >
> > > I tried to add:
> > > pass log quick on $ext_if proto udp from any to any port = 67
> > > in my pf.conf file, didn't help.
> >
> > Completely useless. DHCP traffic never makes its way to pf(4) due to
> > being handled by bpf(4) first, so you don't need such a rule-in fact
> > you could explicitly block such traffic, and it won't matter. Proof:
>
> That may be true for reading dhcp packets, but in some cases
> dhcpleased sends UDP datagram lika any ordinary program, for other
> cases it uses BPF for sending. As the error reported is for sending,
> it *is* possible that pf plays a role.
>
> -Otto
>
> >
> > router# cat /etc/pf.conf
> > # Options.
> > set block-policy drop
> >
> > # Macros.
> > wan = em0
> >
> > # Filtering rules.
> > block in quick on $wan inet proto udp to port 68
> > block out quick on $wan inet proto udp to port 67
> > pass quick
> >
> > router# rcctl stop dhcpcd
> > dhcpcd(ok)
> > router# rm -rf /var/run/dhcpcd/
> > router# ifconfig em0 -inet
> > router# ifconfig em0 -inet6
> > router# ifconfig em0 down
> > router# pfctl -f /etc/pf.conf
> > router# tcpdump -ntt -i em0 -w pkts.dat 'udp and ip and (dst port 67 or
> dst port 68)' &
> > [1] 98425
> > router# tcpdump: listening on em0, link-type EN10MB
> > router# rcctl start dhcpcd
> > dhcpcd(ok)
> > router# pkill -x tcpdump
> >
> > 12551 packets received by filter
> > 0 packets dropped by kernel
> > router# tcpdump -nr pkts.dat
> > 10:02:29.663056 0.0.0.0.68 > 255.255.255.255.67: xid:0x3544268 [|bootp]
> > 10:02:32.802098 0.0.0.0.68 > 255.255.255.255.67: xid:0x3544268 secs:3
> [|bootp]
> > 10:02:32.857942 96.120.140.45.67 > 73.78.65.184.68: xid:0x3544268
> Y:73.78.65.184 G:96.120.140.45 [|bootp] [tos 0x10]
> >
> > The use of dhcpcd(8) is not relevant. I choose to use it for both DHCPv6
> > and DHCP so that I only have one daemon. I am _not_ recommending its
> > use over dhcpleased(8). The point is to show that such traffic is
> > allowed regardless of what rules you have in pf(4).
> >
> > If it is a pf(4) issue, then it not related to that traffic.
> >
>
>
