Re: dhcpleased[59824]: sendto: Permission denied
You did not even look at the list rules. "Do your homework first.. No desire to deprive you of a learning experience." Nobody is here to hold your hand. They do too much of that at work. You must be knowledgeable of the subject. If not, use Google (many web sites for teaching) or switch to FreeBSD with support for the novice. The boss gave up a DARPA research grant rather than make changes for them. On Sat, Jul 8, 2023, 11:42 Mark wrote: > What kind of anger and rudeness is that? > > We're all (at least those who ask questions) learning here. @misc is for > that, right? > > And I think you should learn, too. You must. > > You said it's -no way- related to PF. Yet, it was PF in the end. > > Anyway, stop blindly insulting people here. > > > > Zack Newman , 8 Tem 2023 Cmt, 20:02 tarihinde > şunu yazdı: > > > I am only replying to this in the interest of closure since I am > > already part of this thread, but disclaimer here is some tough love. > > > > You need to stop being lazy and actually understand your network > > topology, the security/privacy real or contrived-I see you adhere to > > the whole security by obscurity nonsense with the masking of the last > > 2 octets of that IPv4 address-and pf. Besides your first attempt at > > "magically" fixing your problem which was doomed to fail for the > > reasons I gave, you are now asking for people to guess what rules you > > need. > > > > Do you "really need to block 'martians'"? Seriously? Ignoring the > > philosophical trap of what you mean by "need", do you even know what a > > "martian" is; and if not, then why are you blindly blocking them? If you > > don't know what you are doing, then just don't do it. I don't even know > > what a "martian" is other than an alien thing from outer space. In the > > interest of providing a modicum of constructive criticism as opposed to > > just criticism, here you go: > > > > > https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml > > . > > > > > https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml > > Not sure if that is what "martians" refer to, but your "martians" > > appear to be a proper subset of what is listed there or at least close. > > With that information, seek out what those blocks mean and decide based > > on your topology and security/privacy needs if you should block > > them. > > > > Should I block 192.168.3.2 on my laptop? What about > > ingress traffic from 2343:24ad:afde:8224::23 destined to UDP port 764 > > on my VPS? Those are obviously rhetorical questions as only I know (or > > at least _should_ know) what my network topology is like, what > > services I run, to whom I want to serve, etc. > > > > You clearly blindly copied and pasted some rules you found without > > knowing what they do or why you are doing it as evidenced by the rather > > embarrassing blocking of your DHCP server. If you are going to be lazy > > and just want stuff to magically work, then disable pf. Bam. Don't need > > to worry about anything. If you plan to block stuff though, then > > actually learn about what you are blocking and why. > > > > Here is a tiny olive branch: I would allow all egress traffic from your > > VPS since that is within _my_ wheel of trust. If my VPS is trying to > > talk to an IP, then either it is already compromised or at least running > > software it shouldn't at which point I have bigger problems; or it > > needs to. Does that "magical" rule apply to you? I don't know, and it > > sounds like you don't either. Even if it does, you will still need to > > decide if you want to allow other IPs to send traffic; but that requires > > you to learn more about your topology, pf, and security/privacy needs. > > > > >
Re: dhcpleased[59824]: sendto: Permission denied
Jul 8, 2023 20:42:57 Mark wrote: > Anyway, stop blindly insulting people here. More blood, more fun.. indeed. I guess this should complaint with some specs from Texas, uh? PS: Mark, don't give it up we are all with you! It is just the next big frontier to do mailing :)
Re: dhcpleased[59824]: sendto: Permission denied
In the interest of transparency, an individual was kind enough to teach me that the term "martian" is in fact defined in RFC 1812: https://www.rfc-editor.org/rfc/rfc1812#page-149 Thank you for the information.
Re: dhcpleased[59824]: sendto: Permission denied
Clearly you cannot read either. Please show me where I said "it's -no way- related to PF". I'm waiting... I'll do the work for you. "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." Hm, looks like I said that PF "certainly could be" the problem. That is literally the first thing I said in this thread. I even concluded that initial e-mail with the following: "If it is a pf(4) issue, then it not related to that traffic." Look at the antecedent there. I did not claim PF was not an issue. What I _correctly_ claimed was that the issue was _not_ related to blocking DHCP traffic on UDP port 67. If that claim is wrong, please prove me wrong. I am not being facetious either. I would love to _learn_ where I am wrong. I'll even go to the lengths of showing you how you could go about proving that claim wrong. See if you have any issues with the following rules: # Options. set block-policy drop # Macros. ext_if = # Filtering rules. block in quick on $ext_if inet proto udp to port 68 block out quick on $ext_if inet proto udp to port 67 pass quick If you have issues, then my claim was in fact wrong. Which is great! I get to learn something. And I think you should learn, too. You must. I agree which is why I learned about my network topology and what rules in my pf.conf(5) do instead of crossing my fingers and hoping some rules I found on the Internet would work. I even offered to learn how exactly your FreeBSD setup worked despite that being a different OS. You never took me up on that offer on trying to understand what is happening though. Instead you were again lazily content that adding a rule to the likely list of rules you didn't even understand was good enough. I will hopefully learn to have much lower standards for the people on @misc, and perhaps wait until I at least have had a cup of coffee before I reply.
Re: dhcpleased[59824]: sendto: Permission denied
What kind of anger and rudeness is that? We're all (at least those who ask questions) learning here. @misc is for that, right? And I think you should learn, too. You must. You said it's -no way- related to PF. Yet, it was PF in the end. Anyway, stop blindly insulting people here. Zack Newman , 8 Tem 2023 Cmt, 20:02 tarihinde şunu yazdı: > I am only replying to this in the interest of closure since I am > already part of this thread, but disclaimer here is some tough love. > > You need to stop being lazy and actually understand your network > topology, the security/privacy real or contrived-I see you adhere to > the whole security by obscurity nonsense with the masking of the last > 2 octets of that IPv4 address-and pf. Besides your first attempt at > "magically" fixing your problem which was doomed to fail for the > reasons I gave, you are now asking for people to guess what rules you > need. > > Do you "really need to block 'martians'"? Seriously? Ignoring the > philosophical trap of what you mean by "need", do you even know what a > "martian" is; and if not, then why are you blindly blocking them? If you > don't know what you are doing, then just don't do it. I don't even know > what a "martian" is other than an alien thing from outer space. In the > interest of providing a modicum of constructive criticism as opposed to > just criticism, here you go: > > https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml > . > > https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml > Not sure if that is what "martians" refer to, but your "martians" > appear to be a proper subset of what is listed there or at least close. > With that information, seek out what those blocks mean and decide based > on your topology and security/privacy needs if you should block > them. > > Should I block 192.168.3.2 on my laptop? What about > ingress traffic from 2343:24ad:afde:8224::23 destined to UDP port 764 > on my VPS? Those are obviously rhetorical questions as only I know (or > at least _should_ know) what my network topology is like, what > services I run, to whom I want to serve, etc. > > You clearly blindly copied and pasted some rules you found without > knowing what they do or why you are doing it as evidenced by the rather > embarrassing blocking of your DHCP server. If you are going to be lazy > and just want stuff to magically work, then disable pf. Bam. Don't need > to worry about anything. If you plan to block stuff though, then > actually learn about what you are blocking and why. > > Here is a tiny olive branch: I would allow all egress traffic from your > VPS since that is within _my_ wheel of trust. If my VPS is trying to > talk to an IP, then either it is already compromised or at least running > software it shouldn't at which point I have bigger problems; or it > needs to. Does that "magical" rule apply to you? I don't know, and it > sounds like you don't either. Even if it does, you will still need to > decide if you want to allow other IPs to send traffic; but that requires > you to learn more about your topology, pf, and security/privacy needs. > >
Re: dhcpleased[59824]: sendto: Permission denied
I am only replying to this in the interest of closure since I am already part of this thread, but disclaimer here is some tough love. You need to stop being lazy and actually understand your network topology, the security/privacy real or contrived-I see you adhere to the whole security by obscurity nonsense with the masking of the last 2 octets of that IPv4 address-and pf. Besides your first attempt at "magically" fixing your problem which was doomed to fail for the reasons I gave, you are now asking for people to guess what rules you need. Do you "really need to block 'martians'"? Seriously? Ignoring the philosophical trap of what you mean by "need", do you even know what a "martian" is; and if not, then why are you blindly blocking them? If you don't know what you are doing, then just don't do it. I don't even know what a "martian" is other than an alien thing from outer space. In the interest of providing a modicum of constructive criticism as opposed to just criticism, here you go: https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml. https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml Not sure if that is what "martians" refer to, but your "martians" appear to be a proper subset of what is listed there or at least close. With that information, seek out what those blocks mean and decide based on your topology and security/privacy needs if you should block them. Should I block 192.168.3.2 on my laptop? What about ingress traffic from 2343:24ad:afde:8224::23 destined to UDP port 764 on my VPS? Those are obviously rhetorical questions as only I know (or at least _should_ know) what my network topology is like, what services I run, to whom I want to serve, etc. You clearly blindly copied and pasted some rules you found without knowing what they do or why you are doing it as evidenced by the rather embarrassing blocking of your DHCP server. If you are going to be lazy and just want stuff to magically work, then disable pf. Bam. Don't need to worry about anything. If you plan to block stuff though, then actually learn about what you are blocking and why. Here is a tiny olive branch: I would allow all egress traffic from your VPS since that is within _my_ wheel of trust. If my VPS is trying to talk to an IP, then either it is already compromised or at least running software it shouldn't at which point I have bigger problems; or it needs to. Does that "magical" rule apply to you? I don't know, and it sounds like you don't either. Even if it does, you will still need to decide if you want to allow other IPs to send traffic; but that requires you to learn more about your topology, pf, and security/privacy needs.
Re: dhcpleased[59824]: sendto: Permission denied
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 , 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.
> >
>
>
Re: dhcpleased[59824]: sendto: Permission denied
On 7/4/23 12:41, Otto Moerbeek wrote: 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 I know which is why I didn't rule out pf as the problem and only the specific exchange that rule was referring to. Of course my example that "proved" you could specifically block the DHCP exchange only pertained to dhcpcd and not dhcpleased.
Re: dhcpleased[59824]: sendto: Permission denied
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. >
Re: dhcpleased[59824]: sendto: Permission denied
On 7/4/23 11:51, Mark wrote: 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.. That does indeed appear to refute my claim about FreeBSD. I am now curious. I know pf in FreeBSD has diverged quite a bit from pf in OpenBSD, so maybe that is relevant. Here is the @misc thread I was referring to FYI: https://marc.info/?l=openbsd-misc=167283774627269=2 If you are willing to entertain me, can you have pf.conf(5) contain the following (and only the following): set block-policy drop set skip on lo ext_if = pass out quick on $ext_if inet proto udp to port 67 pass in quick on $ext_if inet proto udp to port 68 block quick Does dhclient work fine? If so, after removing the two pass lines what does the following write: tcpdump -ntt -i -w pkts.dat 'udp and ip and (dst port 67 or dst port 68)' & Obviously verify the syntax and semantics align with tcpdump on OpenBSD first. Make sure you restart dhclient after you run the above command. Feel free to continue this privately in the interest of not flooding @misc especially since this now concerns an entirely different OS. Zack
Re: dhcpleased[59824]: sendto: Permission denied
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 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=8=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.
Re: dhcpleased[59824]: sendto: Permission denied
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=8=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.
Re: dhcpleased[59824]: sendto: Permission denied
Hi Zack, Very interesting reply. 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. And reading DHCP traffic never makes its way to pf, surprised me. Perhaps that's valid only on OpenBSD but not on FreeBSD? Anyways.. Zack Newman wrote: 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:
Re: dhcpleased[59824]: sendto: Permission denied
Thanks, I'll look into it. Just extended the log rotation interval for messages, daemon and pflog files, to dig about it further. Best. Sven F. , 3 Tem 2023 Pzt, 15:03 tarihinde şunu yazdı: > On Mon, Jul 3, 2023 at 7:42 AM 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. > > > > This is a VPS, getting it's IP from my server provider, through autoconf > > setting. So I assume it's a DHCP access issue? > > > > 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. > > > > Any clue on this please? > > Best. > > OS: OpenBSD 7.3 > > Hello, > > I would log the block rules and check the pledge related log if any ( > in dmesg ? ). > Maybe the configuration received tries to do something unexpected. > > checking pflogd or tcpdump ing pflog will be helpful. > Before adding a dubious pass log. > > Best. > > -- > -- > > - > Knowing is not enough; we must apply. Willing is not enough; we must do >
Re: dhcpleased[59824]: sendto: Permission denied
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: 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.
Re: dhcpleased[59824]: sendto: Permission denied
On Mon, Jul 3, 2023 at 7:42 AM 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. > > This is a VPS, getting it's IP from my server provider, through autoconf > setting. So I assume it's a DHCP access issue? > > 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. > > Any clue on this please? > Best. > OS: OpenBSD 7.3 Hello, I would log the block rules and check the pledge related log if any ( in dmesg ? ). Maybe the configuration received tries to do something unexpected. checking pflogd or tcpdump ing pflog will be helpful. Before adding a dubious pass log. Best. -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
dhcpleased[59824]: sendto: Permission denied
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. This is a VPS, getting it's IP from my server provider, through autoconf setting. So I assume it's a DHCP access issue? 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. Any clue on this please? Best. OS: OpenBSD 7.3
