The t655 — an HP Elite t655 Thin Client doing firewall duty — has OPNsense 26.7 on it as of 2026-10-30. WAN is up over DHCP, GUI access is locked down to one workstation, and that's it: no LAN interface configured, nothing routed yet. Updates are still pending. Writing this down now so future me remembers exactly where this stood before the next phase starts.
Why this box, and what it's for
Picked the t655 over the t640 for this specific job: newer BIOS sitting right at the network edge, and four cores I want available for Suricata later. The storage is eMMC-style flash, which fits this box since it barely writes anyway.
The plan is router-on-a-stick: one cable from the t655 to a single switch port, running as an 802.1Q trunk. VLAN 20 comes up first — that's Phase 1 — with VLAN 10 following later in Phase 3. Once that's live, this box takes over from the switch's stateless ACLs for anything that actually needs stateful filtering. None of that is true yet. Right now it's WAN-only, nothing routing.
Hardware, for the record
- CPU: AMD Ryzen Embedded R2314, 4 cores
- RAM: 4 GB DDR4 SO-DIMM, 2 slots with 1 free, 32 GB max
- Storage: a 64 GB flash module behind a bridge chip, shows up to FreeBSD as
nda0, about 58 GB usable - Wired NIC: Realtek 8168/8111 chipset,
re0 - Wi-Fi: Realtek RTL8852BE — no firmware available for it in OPNsense, so it's dead weight for now
- BIOS: AMI M45 v01.11, dated October 21, 2024
- Power: HP 19.5 V barrel brick
The admin GUI is HTTPS-only; the practice is to check the cert fingerprint against what the console prints rather than trust it blind.
The gotchas — the actual reason to write this down
This is the part worth coming back to.
Never bring a fresh OPNsense install onto a live network with an interface still set to LAN. The default LAN addressing plus an active DHCP server on that interface is a rogue DHCP server waiting to happen.
"No LAN configured" is not the same as "no DHCP server running." Found dnsmasq still listening on the DHCP port with a leftover LAN-range config, even with no LAN interface set up. sockstat -4l | grep ':67 ' is the check to run before trusting a box like this on a live network again.
The setup wizard put re0 back on the LAN role. Recheck the console header after running the wizard, and again after every reboot — don't assume the interface assignment holds.
Finishing the wizard also re-enables the packet filter. Without an existing WAN pass rule, that locks the GUI out. Recovery path: console shell, pfctl -d to drop the filter, add the missing rule, apply it, pfctl -e to turn the filter back on, then reload to confirm it actually took.
The console header is a one-time snapshot from boot, not a live view. A DHCP lease picked up later never shows there. ifconfig re0 | grep "inet ", or just logging out and back in, gets the current answer.
Unchecked "Block private networks" and "Block bogon networks" on WAN. This WAN circuit itself sits on a private address range, so those checkboxes would have blocked the WAN's own legitimate traffic.
Planning to swap in os-realtek-re. FreeBSD's built-in Realtek driver is a known weak spot, and this box's wired NIC depends on it.
Still open
None of this is done yet:
- Confirm the Dnsmasq DNS & DHCP service's Enable box is still unticked
- Download a configuration backup
- Clear the 91 pending firmware updates, install
os-realtek-re, then run a reboot test - Phase 1: bring up a VLAN 20 sub-interface on
re0, flip the switch port from access to trunk, and take over routing for that VLAN
Nothing above is routing live traffic. The two WAN pass rules that exist right now are both scoped to one workstation — one for its Wi-Fi address, one for its wired address — and they exist purely so the GUI stays reachable for admin, not because anything is being forwarded. That's the whole state of the box today.