Openbsd

A colleague looked at my pf.conf last month and said, “That’s it? I thought it’d be longer.”

I took it as a compliment. She didn’t.

She was expecting something impressive. Hundreds of lines of rules, maybe some complex queueing disciplines, an IDS integration, traffic graphs rendered in real time. What she got was about sixty lines of pf rules, two third-party packages, and a box that’s been quietly routing packets for months without anyone noticing it exists.

It’s 3am and your ISP has quietly dropped your WAN connection. Not a hard link-down, nothing that dramatic. The cable modem still has sync, the LEDs are green, DHCP is up. But somewhere between your house and the wider internet, a route has gone stale or a BRAS has crashed or someone at the telco has pushed a config change and not tested it properly. Your firewall has a default route pointing into a void, your DNS queries are timing out, and you’re fast asleep with no idea any of this is happening.

Last July, my firewall rebooted itself at 2pm on a Tuesday. No warning, no panic log, just a clean reboot. I was in a call, so I didn’t even notice until my VPN dropped and I found myself staring at a spinning reconnect icon.

Turned out the CPU had hit 92 degrees. In a fanless box. In a house in Larnaca. In July. The ACPI firmware did exactly what it should do and yanked the power. But 92 degrees means the silicon had been cooking for a while before the hardware killed it, and I hadn’t set up a single layer of monitoring to catch it on the way up.

I was sitting in a cafe in Larnaca last year, waiting for a coffee and idly poking around in packet captures from my home network. I’d just installed a new ISP connection, and I wanted to see what the default DNS behaviour looked like before I started messing with it.

Every single query. In plain text. To my ISP’s resolver.

Every website I visited. Every API endpoint my code called during development. Every smart bulb that phoned home. Every NTP sync, every certificate revocation check, every background update from every device in my house. All of it, neatly logged by my ISP, correlated with my account, timestamped to the millisecond.

Eight days. I’d had the new firewall running for eight days when I pulled up pfctl -s info and stared at the numbers: 61 million packets passed, 325 thousand blocked. Zero percent CPU. The APU3D2 was barely awake. Just sitting there, quietly dropping a quarter of a million packets that had no business being on my network, using roughly the same computational effort as breathing.

I’ve been writing pf rules on and off for about fifteen years, and the thing that still gets me is the syntax. If you’ve ever written iptables rules, you know the feeling of wrestling a language that was designed by committee and refined by people who actively enjoy suffering. pf isn’t like that. pf reads like prose. Not elegant prose, maybe, but clear, declarative, opinionated prose. You read a pf.conf and you can see what the firewall is doing. You don’t need to trace chains and jump targets and figure out which table is evaluated in which order. It’s just… there.

Last month I was reading through the privacy policy of my ISP here in Cyprus. Not for fun, obviously. Nobody reads those for fun. I was looking for something specific about data retention, and halfway down page eleven I found a sentence that made me put my coffee down.

It said, more or less: we may use DNS query data to improve our services and share aggregated data with third parties.