> 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.
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.
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.
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.
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.
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
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.
> 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.
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.
Cool post, I love a good firewall story.
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.
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.
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.
Fun article! I like your watercolors too, especially the one of them going into the pufferfish's mouth :D
Only allowing TCP will break a lot of stuff. I was wondering why even bother with the transport layer, instead of just focusing on IP directly
Love your watercolors! What a fun addition to a technical article :)
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
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.