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.

Love your watercolors! What a fun addition to a technical article :)

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.

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

Fun article! I like your watercolors too, especially the one of them going into the pufferfish's mouth :D

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.