> However, I ran into trouble with the RealTek ethernet hardware support in OpenBSD, which had been running fine with Linux for years.
I've run into problems with realtek gigE nics on Linux, FreeBSD, and Windows. I'm convinced their hardware/firmware has a timing issue where if the wrong things happen, the descriptor indexes get unsyncronized. This can lead to network stalls, but also wild writes. IIRC, reset behavior is weird too; vague because it's been a while since I looked, but I think if you get a network stall and do a reset, the card may receive and DMA a packet into RAM in the process ... something like that anyway.
I have systems where the FreeBSD base driver consistently stalls, but the realtek provided driver works mostly ok; but the realtek driver is full of undocumented flag setting, so who knows what it's doing... it also sets the NIC to emit pause frames when it runs out of RX buffers which I never want; things will be much better if packets are dropped when RX buffers are full.
I would love to have the equipment and time to figure out what's going on, but a) realtek probably should be the ones to do it, b) switching drivers usually works at no cost, and swapping to intel almost always works but you need slots and cards (ebay gets you multiport 1g for $10, 10g for $20-$30 though). I've heard realtek is good at 2.5g and intel isn't; but I haven't run enough realtek 2.5g to know.
One suggestion though: rather than doing this all on a single LAN network and having to deal with adding exceptions for devices that still need access to the Internet during 'bedtime' periods, I suggest creating a separate VLAN for devices that need 'bedtime' enforcement and put those devices there, while leaving your 'always online' devices in your main VLAN where access to the Internet is always available. This way all you have to do is simply change your firewall rules for that VLAN to enforce bedtime, which removes the extra rules needed for exceptions.
This is also the approach I would have used - I was surprised the author didn't end up here. I used a separate VLAN to achieve same thing as author to shutdown internet access on the VLAN my kids devices use at bedtime, as well as another VLAN with no internet access at all for IoT devices, security cameras etc.
Blocking all UDP traffic by default is something I would never have even attempted for a domestic setup either. As the author discovers with Discord and Roblox, a great many common applications and games rely upon it. A UDP block on my kid's VLAN would last about 5 seconds before they attacked me for breaking their online Minecraft games.
The next(I think? It's in -CURRENT now anyway.) version of OpenBSD will be adding VLAN awareness to veb(4). Should make my OpenBSD home router experience much easier.
I tried something like this. my kids just turned off wifi and I can't control the cell signals. Phone parent controls are not powerful enough for what I need
Me too! It was a fantastic addition that I would not have expected. I wish I was artistic enough to do something like that. It had the interesting technical content, with the coziness of a children's book. Really a great piece that the author should be proud of
That little PC should be able to run a lot of additional stuff in addition to the packet filter. My setup is similar, but I use an old gaming PC instead, and run dozens of services including email, nginx and various game servers on it. It does not break a sweat.
Thank you for sharing! What are your thoughts on intentionally degrading service over the course of an hour instead of a hard cutoff? Like implementing an increasingly restrictive cap on download speeds/intentionally dropping a % of packets over the hour. Might be a little less jarring than a hard stop.
The anchor-based approach for time-dependent rules is elegant. Most people would reach for a cron job that rewrites firewall rules on a schedule, but using pf anchors keeps the state management inside the packet filter where it belongs. The key advantage of pf over iptables for this kind of use case is that rule evaluation is deterministic and the syntax stays readable enough to audit six months later without documentation archaeology. Nice to see OpenBSD used for practical home network management instead of just theoretical security posturing.
I had to make something like this at work once (allow access during some hours deny it at other times. and they wanted it enforced at the packet level) and I was a new sys-admin and all I had was an old linux box with iptables. It was ending up as the normal iptables mess until I asked myself "self: how would pf do it?", "anchors. I said, pf would do it with anchors" and I did it that way. well as much as possible. It was by far my cleanest work with iptables.
It has been a while since I have had to mess with iptables but if I remember correctly(quickly reads the iptables man page) the equivalent to pf anchors in iptables is to use named chains then you can faf about loading and unloading the dynamic rules from the chains without messing with the static rules.
The whole thing really made me appreciate the design of pf. I think, strictly speaking, iptables is more capable than pf, but pf and openbsd in general, is far more ergonomic.
> The key advantage of pf over iptables for this kind of use case is that rule evaluation is deterministic and the syntax stays readable enough to audit six months later without documentation archaeology.
Is iptables not deterministic? Don't the packets look at each rule in numerical order until something matches? If you have two rules with the same number, shame on you.
Re archaeology, OpenBSD changed the rules syntax for some reason and the other platforms with pf kept the existing syntax, so that's always a fun game to play.
I've run into problems with realtek gigE nics on Linux, FreeBSD, and Windows. I'm convinced their hardware/firmware has a timing issue where if the wrong things happen, the descriptor indexes get unsyncronized. This can lead to network stalls, but also wild writes. IIRC, reset behavior is weird too; vague because it's been a while since I looked, but I think if you get a network stall and do a reset, the card may receive and DMA a packet into RAM in the process ... something like that anyway.
I have systems where the FreeBSD base driver consistently stalls, but the realtek provided driver works mostly ok; but the realtek driver is full of undocumented flag setting, so who knows what it's doing... it also sets the NIC to emit pause frames when it runs out of RX buffers which I never want; things will be much better if packets are dropped when RX buffers are full.
I would love to have the equipment and time to figure out what's going on, but a) realtek probably should be the ones to do it, b) switching drivers usually works at no cost, and swapping to intel almost always works but you need slots and cards (ebay gets you multiport 1g for $10, 10g for $20-$30 though). I've heard realtek is good at 2.5g and intel isn't; but I haven't run enough realtek 2.5g to know.
One suggestion though: rather than doing this all on a single LAN network and having to deal with adding exceptions for devices that still need access to the Internet during 'bedtime' periods, I suggest creating a separate VLAN for devices that need 'bedtime' enforcement and put those devices there, while leaving your 'always online' devices in your main VLAN where access to the Internet is always available. This way all you have to do is simply change your firewall rules for that VLAN to enforce bedtime, which removes the extra rules needed for exceptions.
Blocking all UDP traffic by default is something I would never have even attempted for a domestic setup either. As the author discovers with Discord and Roblox, a great many common applications and games rely upon it. A UDP block on my kid's VLAN would last about 5 seconds before they attacked me for breaking their online Minecraft games.
It has been a while since I have had to mess with iptables but if I remember correctly(quickly reads the iptables man page) the equivalent to pf anchors in iptables is to use named chains then you can faf about loading and unloading the dynamic rules from the chains without messing with the static rules.
The whole thing really made me appreciate the design of pf. I think, strictly speaking, iptables is more capable than pf, but pf and openbsd in general, is far more ergonomic.
Is iptables not deterministic? Don't the packets look at each rule in numerical order until something matches? If you have two rules with the same number, shame on you.
Re archaeology, OpenBSD changed the rules syntax for some reason and the other platforms with pf kept the existing syntax, so that's always a fun game to play.