Skip to content

TrueNAS Networking Gotchas

The canonical, actively-maintained doc for this lives in the main repo: config/truenas/asymmetric-routing-fix.md. This page is a pointer and summary — read the full doc before touching routing on either box, since it has the exact systemd unit contents and verification commands.

The short version

Both TrueNAS boxes have two NICs on directly-connected subnets (LAN and VLAN 20). Any reply to cross-VLAN traffic naturally wants to exit via whichever NIC the kernel's default route picks for that destination — not necessarily back the way the request came — and pfSense's if-bound state policy drops replies it doesn't recognize as belonging to the connection it's tracking. Symptoms have included:

  • SMB writes across VLANs stalling and resetting after 20-80 seconds, while pings and small transfers worked fine
  • ESXi iSCSI/VMFS journal timeouts and datastores going inaccessible
  • (2026-07-11) A Docker/Apps container unable to SSH into a service on its own host — the reply routed out to pfSense instead of back to the container's bridge

The fix, in one line

Policy-based routing (pbr-mgmt20.service) that pins replies from each interface's IP to leave via that interface's own gateway, plus (as of the Docker extension) a priority-50 rule that exempts anything destined for a docker bridge subnet (172.16.0.0/16) from that source-based routing entirely, so bridge traffic always uses the directly-connected route regardless of source.

Upgrade caveat

This is a hand-rolled systemd unit — it does not survive a TrueNAS version upgrade (each upgrade boots a fresh boot environment). After upgrading either box, re-create it from the repo doc before assuming a post-upgrade networking issue is something new.