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. beebeet...@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 ! 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
Re: Unexpected pf behavior for DHCP traffic?
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. beebeet...@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 ! > 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 >
Re: WireGuard host crashes roughly every week
looks like OOM problem, Send dmesg, keep a window withlog open, monitor your memory usage with something also send some conf On Thu, Jul 29, 2021 at 9:11 PM Matt P. wrote: > > Hi all. > > I have an OpenBSD box that breaks after a week or so of running. All network > traffic stops reaching the box. If I look at the screen or serial output, I > can get the "login:" prompt, and when I enter my name I get prompted for a > password, but once I enter a password it hangs. Key presses and control codes > still show on the screen, but the login never succeeds or fails. I thought > control-C might cause it to go back to the login prompt, but it doesn't. I > have to hard reboot the box to get it back. > > This box runs a Wireguard server accessible from the internet, and I think > it's related to the crashing. I used to run the same WireGuard configuration > on a different OpenBSD machine (a Raspberry Pi instead of x64), and the same > crashing would happen. I blamed the crashing on the Pi port of OpenBSD, which > is why I switched machines, but it stopped happening on the Pi and started on > the x64 box. > > I'm a newbie at systems administration, and don't know where to go from here. > There's no kernel panics to send, and I didn't see anything in the log files > about the crash. What should I do? > > --Matt > -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
Unexpected pf behavior for DHCP traffic?
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 ! 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
WireGuard host crashes roughly every week
Hi all. I have an OpenBSD box that breaks after a week or so of running. All network traffic stops reaching the box. If I look at the screen or serial output, I can get the "login:" prompt, and when I enter my name I get prompted for a password, but once I enter a password it hangs. Key presses and control codes still show on the screen, but the login never succeeds or fails. I thought control-C might cause it to go back to the login prompt, but it doesn't. I have to hard reboot the box to get it back. This box runs a Wireguard server accessible from the internet, and I think it's related to the crashing. I used to run the same WireGuard configuration on a different OpenBSD machine (a Raspberry Pi instead of x64), and the same crashing would happen. I blamed the crashing on the Pi port of OpenBSD, which is why I switched machines, but it stopped happening on the Pi and started on the x64 box. I'm a newbie at systems administration, and don't know where to go from here. There's no kernel panics to send, and I didn't see anything in the log files about the crash. What should I do? --Matt
Re: Where to sleep to wait for lease
Hi Leon, On Wed, Jul 28, 2021 at 08:18:41PM +0200, Leon Fischer wrote: | > no IP address found for vlan34:0 | > /etc/pf.conf:56: could not parse host specification | > pfctl: Syntax error in config file: pf rules not loaded | | Sleeping isn't needed if the address in pf.conf(5) is parenthesized: | | pass out to (vlan34:0) You are right - that solves my issue, thanks for the reminder. Interestingly enough, most other rules in my pf.conf use the parenthesized interface name, can't recall why I didn't use that in this instance. I now have: pass in on $extIF inet proto udp from to ($extAddr) port $wgport Where $extIF is 'vlan34' and $extAddr is 'vlan34:0'. This is better than additional delays during boot. Thanks again! Paul -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/