Lots of changes to the website

content/posts/openbsd-to-opnsense.md

@@ -0,0 +1,86 @@
+---
+title: "Why I Moved fw01 from OpenBSD to OPNsense"
+date: 2026-03-17
+tags: [openbsd, opnsense, networking, homelab]
+slug: openbsd-to-opnsense
+description: "I love OpenBSD. I still moved my firewall to OPNsense. Here's the honest account of why."
+draft: false
+---
+
+I wrote a post not long ago about why I chose FreeBSD for this homelab. I could write a
+nearly identical one about OpenBSD on the firewall. The man pages, the security posture, pf —
+OpenBSD is one of the most coherent operating systems I've ever used, and fw01 ran it well.
+
+So why did I replace it with OPNsense?
+
+I wrestled with this for longer than I probably should have. Changing your firewall feels like
+a statement. I've written about pf. I've defended the "just learn the config file" approach.
+Switching to a web UI felt like a betrayal of something.
+
+But pragmatism won.
+
+## The Actual Problem
+
+My ISP bumped me to a 2 Gb/s connection. Theoretically great. In practice, I needed my
+firewall to actually push that throughput across the NICs I had available.
+
+OPNsense gave me more flexibility in how those interfaces were handled — driver support,
+offloading options, tuning knobs exposed through the UI. Getting the same result on OpenBSD
+would have meant more digging, more testing, more time spent on the firewall instead of
+everything the firewall is supposed to protect.
+
+I didn't want to spend a weekend tuning network drivers. I wanted 2 Gb/s to work.
+
+## Why Not pfSense
+
+Before this homelab, I ran a Netgate 4200 with pfSense. It worked fine, but the UI felt
+like it hadn't been touched since 2012. Cluttered, inconsistent, hard to navigate. Every
+time I needed to do something non-obvious I was digging through three menus wondering if I
+was in the right place.
+
+OPNsense is a different experience. The interface is clean, the layout makes sense, and it
+moves at a pace that feels like a maintained project. It's also based on FreeBSD — so under
+the hood, it's still pf, still the networking stack I trust.
+
+Choosing OPNsense wasn't a hard call once pfSense was off the table.
+
+## The Migration
+
+I expected this to be painful. It wasn't. My pf rules translated cleanly. VLAN configuration
+that I'd built up over time moved over without drama. The concepts are identical because
+the underlying system is the same — OPNsense just wraps it.
+
+If you're coming from OpenBSD's pf, OPNsense's firewall rules section will feel familiar.
+The mental model is the same. You're still thinking in terms of interfaces, states, and
+explicit allows. The GUI is just a different way of expressing those rules.
+
+## The Part I Didn't Expect to Care About
+
+Here's the thing I didn't anticipate valuing: if something goes wrong with the firewall
+while I'm not home, someone in my family can actually do something about it.
+
+With a text config and an SSH session, the answer to "the internet is down" is "call me and
+I'll walk you through it." With OPNsense, it's "open a browser, log in, click here, click
+there." That's a meaningful difference in a home environment.
+
+I'm not designing a data center. I'm running a homelab that also happens to be the internet
+connection for my household. Resilience includes other humans being able to use it.
+
+## What I Gave Up
+
+I won't pretend there's no loss here. OpenBSD's simplicity is real. The config file is
+auditable in a way no web UI ever fully is. There's a directness to `pfctl -sr` that no
+amount of GUI polish replicates.
+
+But I still have pf. I still have the BSD networking stack. The firewall is still doing
+exactly what I'd configure it to do manually — I'm just configuring it differently.
+
+## The Honest Takeaway
+
+Sometimes the right tool isn't the purist choice.
+
+I still believe in OpenBSD. I still think pf is the best firewall I've used. None of that
+changed. What changed was an honest accounting of what I actually needed from this specific
+machine — throughput, flexibility, and something my household can survive without me.
+
+OPNsense delivered that. The ideology didn't need to.

content/posts/pf-vlans.md

@@ -25,7 +25,7 @@ Five VLANs, each on a different subnet:
 | game | 30  | 10.0.30.0/24  | Game clients and VMs           |
 | iot  | 40  | 10.0.40.0/24  | Untrusted / IoT / Guest        |
 
-The physical layout: one NIC on fw01 is trunked to the main switch. OpenBSD VLAN interfaces
+The physical layout: one NIC on fw01 is trunked to the main switch. OPNsense VLAN interfaces
 (`vlan10`, `vlan20`, etc.) are configured on top of it. Each VLAN interface gets an IP address
 in its respective subnet and acts as the default gateway for devices in that VLAN.
 

content/posts/site-is-live.md

@@ -1,20 +1,20 @@
 ---
 title: "ridgwaysystems.org is live"
 date: 2026-03-11
-tags: [meta, go, openbsd]
+tags: [meta, go, freebsd]
 slug: site-is-live
-description: "The site is up. A single Go binary on OpenBSD, serving blog posts, a status page, a hire page, and an admin panel — no database, no Docker, no external dependencies."
+description: "The site is up. A single Go binary on FreeBSD, serving blog posts, a status page, a hire page, and an admin panel — no database, no Docker, no external dependencies."
 draft: false
 ---
 
 It's up.
 
-ridgwaysystems.org is now running on a Vultr VPS — OpenBSD, relayd for TLS termination, a single Go binary handling everything behind it. No database. No Docker. No framework. Flat Markdown files on disk, templates compiled into the binary at startup, HMAC-signed sessions, and a background goroutine that checks service health every few minutes.
+ridgwaysystems.org is now running on a Vultr VPS — FreeBSD, nginx for TLS termination, a single Go binary handling everything behind it. No database. No Docker. No framework. Flat Markdown files on disk, templates compiled into the binary at startup, HMAC-signed sessions, and a background goroutine that checks service health every few minutes.
 
 The stack:
 
 - **Go** — stdlib `net/http` with 1.22 pattern routing. One binary, one deploy, done.
-- **OpenBSD** — relayd as the reverse proxy, acme-client for TLS certs, rc.d for service management.
+- **FreeBSD** — nginx as the reverse proxy, certbot for TLS certs, rc.d for service management.
 - **Flat files** — posts are `.md` files in `content/posts/`. The status page reads from `data/status.json`. Newsletter subscribers live in `data/subscribers.json`.
 - **No build step** — CSS is hand-written, no preprocessor. JS is a single file for the admin editor.
 
@@ -22,4 +22,4 @@ Features that made it in before launch: blog with next/prev navigation, a status
 
 The source is at [git.ridgwaysystems.org](https://git.ridgwaysystems.org).
 
-More build posts to follow — the relayd config alone is worth documenting.
+More build posts to follow — the nginx config alone is worth documenting.

content/posts/the-hardware.md

@@ -13,10 +13,10 @@ actually in the rack, why those machines, and what each one does.
 ## The Firewall: SuperMicro 1U
 
 The firewall is a SuperMicro 1U server with a Xeon E3-1230v2 and 16GB ECC RAM. This runs
-OpenBSD and handles everything at the network edge:
+OPNsense (FreeBSD-based) and handles everything at the network edge:
 
 - **pf** — stateful packet filtering, VLAN routing
-- **relayd** — reverse proxy, TLS termination for external services
+- **nginx** — reverse proxy, TLS termination for external services
 - **WireGuard** — VPN for remote access
 - **unbound** — recursive DNS resolver for internal clients
 - **dhcpd** — DHCP for all VLANs
@@ -32,7 +32,7 @@ network segment.
 The R720 is the workhorse. Dual Xeon E5-2600 series processors, 64GB ECC RAM, a few SSDs
 for the OS and data volumes.
 
-This runs OpenBSD and hosts:
+This runs FreeBSD and hosts:
 
 - **httpd** — web server for this site
 - **Gitea** — self-hosted git
@@ -51,18 +51,18 @@ on a home circuit without thinking about it.
 ## The Secondary Server: Dell R710
 
 The R710 is older — Xeon 5500/5600 series — but has more RAM slots, currently at 48GB.
-It runs a mix of OpenBSD base with some Linux VMs managed by `vmm(4)`.
+It runs FreeBSD with Linux VMs managed by `bhyve(8)`.
 
 Primary roles:
 
 - **nsd** — authoritative DNS for ridgwaysystems.org zones
-- **Linux VMs** — game servers (Minecraft, Valheim, etc.), running in `vmm(4)`
+- **Linux VMs** — game servers (Minecraft, Valheim, etc.), running in `bhyve(8)`
 - **Jellyfin** — media server
-- **Backup target** — receiving rsync backups from srv01
+- **Backup target** — receiving ZFS send/recv and rsync backups from srv01
 
 The R710 is even louder than the R720 under load. Old server hardware wasn't designed with
-home environments in mind. ILO (Dell iDRAC) makes remote management workable — I rarely
-need to touch it physically.
+home environments in mind. iDRAC makes remote management workable — I rarely need to touch
+it physically.
 
 ## The Desktop: Daily Driver and Ansible Control Node
 
@@ -95,4 +95,4 @@ data. ECC doesn't eliminate all failure modes, but it eliminates the commonest o
 
 Next up: the pf configuration and VLAN setup. This is where most of the interesting work
 happens — separating untrusted IoT devices from servers, routing WireGuard traffic, and
-setting up relayd to proxy external services.
+setting up the reverse proxy to forward external services.

content/posts/why-openbsd.md

@@ -1,35 +1,40 @@
 ---
-title: "Why OpenBSD for a Homelab"
+title: "Why FreeBSD for a Homelab"
 date: 2026-03-01
-tags: [openbsd, homelab]
-slug: why-openbsd
-description: "The case for running OpenBSD as the foundation of a homelab — security model, pf, clean base system, and the value of good documentation."
+tags: [freebsd, homelab]
+slug: why-freebsd
+description: "The case for running FreeBSD as the foundation of a homelab — ZFS, jails, pf, clean base system, and the value of good documentation."
 draft: false
 ---
 
-A few people have asked why I chose OpenBSD for this homelab instead of the usual suspects —
+A few people have asked why I chose FreeBSD for this homelab instead of the usual suspects —
 Proxmox, TrueNAS, some flavor of Linux. The short answer: I wanted to actually understand what
-my infrastructure is doing, and OpenBSD forces that in a way nothing else does.
+my infrastructure is doing, and FreeBSD forces that in a way nothing else does.
 
-## The Security Model Is Different
+## ZFS Is the Right Filesystem
 
-Most operating systems bolt security on. OpenBSD builds it in.
+FreeBSD ships ZFS in the base system and it's a first-class citizen. Copy-on-write,
+checksumming, snapshots, send/receive for replication, compression, deduplication. For a
+homelab running storage workloads, ZFS means you actually trust your data is what you think it is.
 
-`pledge(2)` and `unveil(2)` are the clearest expression of this. Programs declare up front exactly
-what syscalls they'll use and which filesystem paths they'll touch. The kernel enforces it. If a
-daemon gets compromised, the blast radius is bounded by what it pledged. This isn't theoretical —
-the base system uses these everywhere.
+Compare that to the ext4/LVM dance on Linux — it works, but you're stitching together multiple
+tools to get what ZFS gives you out of the box.
 
-Compare that to a typical Linux daemon running as root (or even a non-root user) with access to
-the full filesystem. The attack surface is enormous by default.
+## Jails Are the Right Way to Isolate Services
+
+FreeBSD jails give you lightweight OS-level isolation without the overhead or complexity of VMs,
+and without the moving parts of Docker. A jail is just a restricted process tree with its own
+filesystem view. Predictable, auditable, and you control exactly what it can see.
+
+The security model is sound. A compromised service in a jail can't reach the host or other jails
+without explicit configuration. Compare this to a typical Linux container where the security
+boundary depends on which kernel namespaces you've set up correctly.
 
 ## pf Is the Best Firewall I've Used
 
-I've spent time with iptables, nftables, and a few others. `pf(4)` is in a different category.
-
-The rule syntax reads like English. State tracking is intelligent by default. `relayd(8)` handles
-reverse proxying and TLS termination in a way that integrates naturally with pf. The whole
-networking stack hangs together coherently.
+FreeBSD ships pf — the same packet filter that made BSD firewalls famous. The rule syntax reads
+like English. State tracking is intelligent by default. The whole networking stack hangs together
+coherently.
 
 Here's a minimal pf.conf to give a sense of the syntax:
 
@@ -47,37 +52,32 @@ That's readable. You can audit that in two minutes.
 
 ## The Base System Is Clean
 
-OpenBSD ships a complete, minimal base system. No package manager drama, no systemd, no
-six-hundred-dependency init system. The base is coherent. Everything in `/usr/bin` and
-`/sbin` has been reviewed and fits together.
+FreeBSD ships a complete, coherent base system — separate from ports and packages. No systemd.
+Everything in the base has been considered deliberately and fits together.
 
 When I install a service, I know exactly what I'm adding on top of a well-understood foundation.
 On a typical Linux distro, I'm never quite sure what's lurking in the base.
 
 ## The Documentation Is Accurate
 
-This is underrated. OpenBSD man pages are written by the people who wrote the code. They are
-current. They are correct. When the man page says `pledge(2)` takes these promises in this
-order, that is exactly what happens.
+The FreeBSD Handbook is one of the best pieces of technical documentation in open source. The
+man pages are maintained by the people who wrote the code. When the Handbook describes how to
+set up ZFS or configure pf, it describes what actually happens.
 
-How many times have you followed a Linux man page only to find it describes behavior from four
-kernel versions ago? Or read documentation that's accurate for one distro but not another?
-
-With OpenBSD, the man page is the specification. This matters enormously when you're learning
-a new tool or debugging an obscure issue at 2am.
+With FreeBSD, the documentation and the system agree with each other. This matters enormously
+when you're learning a new tool or debugging an obscure issue at 2am.
 
 ## The Tradeoffs
 
-OpenBSD isn't the right choice for everything. ZFS isn't in the base (use FreeBSD for that).
-The package ecosystem is smaller than Linux. Some software just doesn't run on OpenBSD, or
-runs with limitations.
+FreeBSD isn't the right choice for everything. The package ecosystem is smaller than Linux.
+Some software just doesn't run on FreeBSD, or requires extra effort to get working.
 
 For a homelab where the goal is to *understand* the infrastructure rather than just consume
 services, these tradeoffs are worth it. The constraint of a smaller, more deliberate ecosystem
 means you end up with a leaner, more auditable system.
 
-If you want to run Kubernetes on your homelab, OpenBSD is the wrong choice. If you want to
-actually know what your firewall is doing and why, it's worth the investment.
+If you want a point-and-click hypervisor, use Proxmox. If you want to actually know what your
+firewall is doing and why, FreeBSD is worth the investment.
 
 ## What's Next