OPNsense uses Dnsmasq for DHCP, not Kea or ISC dhcpd. (Kea was upgraded 2.x → 3.0.2 during the firmware update but isn’t enabled.)

Why almost nothing has a static reservation

Mac Studio is the only host with a DHCP reservation. We deliberately did NOT add reservations for hpve, the CTs (Pi-hole, Caddy, docker-host, Immich, vaultwarden), or any other LAN device. Reasoning:

• CTs use static IPs configured at the Proxmox level, not via DHCP. CT100 = 192.168.8.100, CT101 = .103, CT102 = .53, CT103 = .54, CT105 = .105 (Roon). (CT104 was retired May 2026.) These are baked into the LXC config (/etc/pve/lxc/<vmid>.conf), so they survive across reboots and don’t depend on the DHCP server at all. Adding a reservation for them would be redundant and only adds a place where the IP could be defined inconsistently.
• hpve uses a static IP configured in /etc/network/interfaces (192.168.8.221). Same reasoning — the host doesn’t ask DHCP for an address.
• Eero mesh nodes are in bridge mode and get whatever DHCP gives them. They’ve never moved off their initial leases (.123, .140, .169, .203, .212), so they’re effectively stable. If they ever do roam, no service depends on a specific eero IP.
• Smart-home devices (Sonos, WiiM Ultra, YouTube TV, Brother printers, Homey, Weather Station) all keep stable leases through normal DHCP renewal. Most have hostnames in mDNS/Bonjour anyway, so we use names not IPs to reach them.

Mac Studio is the exception because it has services bound to a specific IP (Hugo Hub, Paperless-NGX, LM Studio, Life Archive API/MCP) that other hosts and the Bee Hub site link to by IP. Drifting onto a different IP would break those references.

When to revisit: any time we add a service on a non-CT host that other systems reference by IP, the host should get a reservation.

OPNsense’s Unbound is the DNS resolver on port 53. Dnsmasq does DHCP only.

Critical config: Unbound has a <privateaddress> filter that blocks RFC1918 answers from public DNS (default behavior). Cloudflare’s wildcard *.edmd.me → 192.168.8.54 would normally be filtered out and clients would get NXDOMAIN.

The fix is a forward override added Apr 29 2026:

edmd.me → 192.168.8.53:53 (Pi-hole)

Configured via the OPNsense Unbound model (<unboundplus><dots><dot type="forward">). UUID 27b78f0f-57b1-40f7-9169-69cfd6d1d467. Pi-hole then returns the right answer for *.edmd.me.

Without this, Mac/iOS clients that route edmd.me queries to OPNsense (because of the search-domain hint) would fail to resolve — even though Pi-hole has the correct entry.

ssh root@192.168.8.1
configctl firmware poll       # Check for available
configctl firmware update     # Apply all pending updates
# NOTE: NOT 'firmware upgrade' — that's for major version bumps with named target

The Apr 29 firmware run applied 135 packages including:

• Kea: 2.6.3 → 3.0.2 (DHCP — not used; we run Dnsmasq)
• acme.sh: 3.1.1 → 3.1.2
• openssl: → 3.0.18
• bind-tools, krb5, glib, dpinger, filterlog

Reboots automatically when needed. The system regenerates SSH host keys on upgrade — clear ~/.ssh/known_hosts for 192.168.8.1 after upgrades. Authorized keys for root are wiped and must be re-added via web UI: System → Access → Users → root → Authorized keys.

Pre-update XML config backup is saved on the Mac Studio at:

~/homelab-backups/opnsense-orchard-preupdate-YYYYMMDD-HHMMSS.xml

Take a backup before every firmware update:

ssh root@192.168.8.1 'cp /conf/config.xml /tmp/opnsense-config.xml'
scp root@192.168.8.1:/tmp/opnsense-config.xml ~/homelab-backups/opnsense-orchard-$(date +%Y%m%d-%H%M%S).xml

To restore, boot the OPNsense installer ISO and use “Import config” — point it at the XML.

The home internet has a double-NAT at the ISP level — OPNsense’s WAN IP is 192.168.254.65 (RFC1918), behind an ISP-managed gateway at 192.168.254.254 that we don’t control.

Consequences:

• No IPv6 — ISP gateway doesn’t pass it through to OPNsense.
• No inbound port forwarding to the home — UDP 51820 (NetBird WireGuard direct P2P) cannot be opened from the public internet.
• No outbound ICMP from OPNsense to the upstream gateway — ping 192.168.254.254 and even ping 1.1.1.1 from OPNsense itself fails. TCP works fine. Diagnostic-only annoyance.

These would be solved by a different ISP service tier with a real public IP, not by anything OPNsense can do.

• Rotate root password — lloovies was passed in chat during setup
• Lock admin services to NetBird subnet only — SSH (22), web UI (443), should not accept connections from arbitrary LAN clients. Add WAN/LAN firewall rules limiting source to 100.123.0.0/16.
• Lock hpve admin too — Proxmox 8006 and Cockpit 9090 should also be NetBird-only. UFW on hpve.
• Install vespo92/OPNSenseMCP — for managing OPNsense from Claude Desktop (API-only, no SSH).

If web UI and SSH stop responding but routing still works (we hit this once on cutover day):

1. Plug a monitor and keyboard into the OPNsense box.
2. Console menu appears at boot — login with root / lloovies.
3. Option 11) Reload all services usually fixes it.
4. Option 6) Reboot as a stronger reset.
5. Option 8) Shell to investigate (tail -f /var/log/system/latest.log).

If the device won’t boot or has a bad config, restore from XML backup via the installer ISO’s “Import config” prompt.