2026 Homelab Stack: OPNsense + Proxmox + TrueNAS + 10GbE

A recurring homelab pattern on r/homelab and r/Proxmox in 2026 pairs OPNsense for routing and firewalling, Proxmox VE as the hypervisor, TrueNAS (usually as a VM or dedicated box) for ZFS storage, and a 10GbE backbone tying it together. None of these pieces are new individually, but the combination — and the specific configuration choices that make it reliable — is what separates a homelab that stays up from one that needs constant babysitting.

This synthesis walks through how the four pieces fit, what 10GbE hardware actually costs in dollars and watts, where TrueNAS sits relative to Proxmox's own storage options, and the tuning steps (jumbo frames, VLANs, CARP) that show up across public writeups of this stack.

Why This Stack? OPNsense, Proxmox, TrueNAS, and 10GbE Explained

Each layer has a distinct job:

• OPNsense — the router/firewall, running either on dedicated hardware or as a Proxmox VM with a passed-through or SR-IOV-virtualized WAN NIC.
• Proxmox VE — the hypervisor hosting OPNsense, TrueNAS (if virtualized), and everything else: media servers, *arr stack containers, a Pi-hole or AdGuard VM, CI runners, whatever the lab is for.
• TrueNAS — ZFS-backed storage, exposed to Proxmox over NFS or iSCSI for VM disks and to the rest of the network over SMB/NFS for files.
• 10GbE — the fabric between Proxmox and TrueNAS (and any other node) so storage isn't bottlenecked at 1Gb's roughly 110MB/s real-world ceiling.

The appeal is separation of concerns: storage failures don't take out the router, and the router's config lives independently of whatever chaos is happening in the VM pool. The tradeoff is complexity — four systems to patch and monitor instead of one all-in-one NAS-router appliance. Builders coming from a single Raspberry Pi doing double duty as router and Pi-hole, like the setups covered in /reviews/raspberry-pi-4-8gb-homelab-2026, tend to grow into this stack once VM count and storage needs outgrow a single small board.

Configuring OPNsense on Proxmox: VLANs, CARP, and SR-IOV

VLAN segmentation

OPNsense's own manual covers 802.1Q VLAN tagging directly on the interface configuration page, and the common homelab pattern is to run one tagged trunk into OPNsense and break it into VLANs for management, trusted LAN, IoT/guest, and a dedicated storage VLAN for TrueNAS-to-Proxmox traffic. Keeping storage traffic on its own VLAN (and ideally its own physical 10GbE link) avoids ARP broadcast noise and contention with normal client traffic.

CARP for firewall high availability

OPNsense documents Common Address Redundancy Protocol (CARP) for running two firewalls that share a virtual IP, so a second unit can take over if the primary drops. This is more setup than most single-firewall homelabs need, but it's the documented path for anyone treating the router as critical infrastructure rather than a single point of failure — relevant if OPNsense is virtualized and shares a Proxmox host with everything else it protects.

SR-IOV for VM networking

When OPNsense runs as a Proxmox VM, Proxmox's SR-IOV documentation describes letting a physical NIC present multiple virtual functions directly to VMs, which cuts the CPU overhead of software bridging versus a standard virtio bridge. It requires NIC and motherboard support (Intel's server-class NICs are the most commonly supported in the homelab community) and is generally reserved for the WAN-facing NIC handling the router's traffic, not every VM's network interface.

10GbE Hardware for a 2026 Homelab

10GbE pricing has come down enough that used enterprise NICs and small managed switches are now standard homelab shopping list items rather than a splurge.

Intel's X550 series remains a common recommendation for RJ45 10GbE in Proxmox and TrueNAS boxes because of mature, well-tested Linux/FreeBSD driver support. Aquantia (now Marvell) AQC-series chips show up on consumer motherboards and add-in cards as a lower-cost RJ45 alternative, with driver maturity that has improved significantly but historically lagged Intel's in some BSD-based platforms — worth checking against your specific TrueNAS/OPNsense version before buying. On the switch side, Cisco's small-business managed switch lines are a frequent homelab pick for combining multiple SFP+ or 10GBASE-T uplink ports with a larger pool of 1GbE access ports for the rest of the network.

Cabling cost is the detail that surprises newcomers: short DAC cables for SFP+ runs are inexpensive, but Cat6a for reliable 10GBASE-T runs longer than a few meters costs meaningfully more than the Cat5e/Cat6 already in most walls, and may require a re-run rather than reusing existing drops.

TrueNAS on Proxmox: Storage Architecture, Not a Benchmark Contest

TrueNAS is built on ZFS — pooled storage with checksumming, snapshots, and options for mirrored or RAID-Z redundancy. The homelab question isn't usually "ZFS vs. Btrfs" inside TrueNAS (TrueNAS doesn't offer Btrfs), it's how to connect ZFS storage to Proxmox VMs:

• NFS — simplest to set up, good for general VM disk storage and container bind mounts.
• iSCSI — block-level access, generally preferred for VM disks where you want Proxmox to manage the block device directly rather than a file-backed image over NFS.

ZFS's read cache (ARC) lives in RAM by design — more memory on the TrueNAS box directly improves cache hit rates for frequently-read data, which is why TrueNAS's own guidance leans toward "more RAM" as the first upgrade for a storage-heavy pool before reaching for a dedicated cache or log device. A separate SLOG (write log) device, typically a fast NVMe drive, helps synchronous write-heavy workloads like databases or VM disks over NFS with sync writes enabled — but it doesn't help asynchronous workloads and isn't a substitute for having enough spinning or SSD capacity in the pool itself.

For smaller or budget-constrained storage layers feeding a homelab NAS, the SSD selection guidance in /reviews/best-ssd-raspberry-pi-homelab-2026 and /reviews/best-budget-ssd-retro-homelab-2026 applies just as well to a TrueNAS boot or cache drive as to a Pi-based NAS.

Network Tuning: Jumbo Frames, Offload, and QoS

A few tuning steps show up repeatedly in public homelab writeups of this stack:

1. Jumbo frames (MTU 9000) on the dedicated storage VLAN — set consistently on the TrueNAS NIC, the Proxmox host NIC, and the switch port/VLAN, per Proxmox's network configuration documentation. A mismatched MTU anywhere in the path causes fragmentation and can make throughput worse than the 1500-byte default, so this is an all-or-nothing change, not a per-device toggle.
2. NIC offload features — checksum offload, TSO/LRO — are generally left at their driver defaults on Intel-based 10GbE NICs, which have mature offload support; some homelabbers report needing to disable specific offload features on less mature Aquantia/Marvell drivers when troubleshooting throughput issues, though this is workload- and driver-version-specific rather than a universal rule.
3. QoS/traffic shaping in OPNsense — useful for keeping a saturating backup job or torrent VM from starving interactive traffic, configured per-interface or per-VLAN in OPNsense's traffic shaper.

CPU and Platform Choice for a Homelab Node

The CPU running Proxmox (and by extension OPNsense and possibly TrueNAS as VMs) has to balance idle power draw against burst capacity for VM workloads. Two poles show up in community builds:

For a single-node lab running OPNsense plus a modest VM count, a mid-range chip is usually enough — see the real-world account in /reviews/homelab-month-one-ryzen-5-5600g-enough-2026 and the broader first-month retrospective at /reviews/started-homelab-a-month-ago-am-i-doing-it-right. Cooling matters more than most first-time builders expect once a box runs 24/7 in a closet or rack — the same VESA-mount and airflow considerations covered for compact Pi builds in /reviews/silent-pi-4-nvme-homelab-cooling-vesa-2026 apply directly to a small-form-factor x86 Proxmox node.

Keeping the Rack Healthy: A Basic Electrical Toolkit

Once a homelab has a PDU, a UPS, and several PSUs feeding a switch, NAS, and hypervisor box, basic electrical diagnostics become genuinely useful — confirming a PSU's 12V rail is actually holding under load, checking that a PoE injector is outputting the voltage it claims, or verifying a suspect outlet before blaming a component. A general-purpose digital multimeter like the AstroAI TRMS 6000-count multimeter covers DC voltage checks on PSU rails and continuity testing on suspect cabling, while a clamp meter like the KAIWEETS HT206D reads current draw without breaking a circuit — useful for confirming a UPS or PDU circuit isn't close to its rated amperage before adding another 10GbE switch to the load.

Where to Go Next

Builders scaling up from a single Raspberry Pi to this four-part stack, or scaling down for a lower-power satellite node, may find these related teardowns useful: the Pi 4 vs. Pi 5 comparison at /reviews/raspberry-pi-4-8gb-vs-pi-5-homelab-2026, and a compact NVMe-based Jellyfin box at /reviews/raspberry-pi-4-nvme-jellyfin-homelab-2026 for a low-power media-serving satellite that can sit on the same 10GbE-backed storage VLAN as the main TrueNAS box.

Citations and sources

• OPNsense VLAN manual
• OPNsense High Availability / CARP manual
• Proxmox VE SR-IOV wiki
• Proxmox VE Network Configuration wiki
• TrueNAS SCALE documentation
• TrueNAS documentation home
• Intel 10 Gigabit Ethernet overview
• Cisco Small Business 350 Series managed switches
• AMD Ryzen 7 7800X3D product page

This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.