My home network observes bedtime with OpenBSD and pf

toast0 26 minutes ago | parent | next [-]

> 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.

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.

▲

pak9rabid 2 hours ago | parent | prev | next [-]

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.

	▲	mtlmtlmtlmtl 5 minutes ago \| parent \| next [-]
		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.
	▲	giobox an hour ago \| parent \| prev [-]
		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.

▲

foobarian 17 minutes ago | parent | prev | next [-]

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

▲

deanputney 2 hours ago | parent | prev | next [-]

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

	▲	freedomben 8 minutes ago \| parent [-]
		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

▲

panavinsingh an hour ago | parent | prev [-]

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.