Skip to content
daniel@cosenza:~/blog
FreeBSDFix March 4, 2026 3 min read

Fixing FreeBSD Jail Networking When VNET Jails Can't Reach the Network

A jail starts fine but has no network connectivity, or can't reach the host — usually a VNET/epair configuration problem, not a jail bug.

A jail that starts cleanly but can’t reach the network — or that the host can’t reach — is almost always a networking configuration problem specific to how the jail’s virtual network stack was set up, not a problem with jails generally.

Step 1: confirm whether the jail is VNET or shares the host stack

jls -v | grep -A2 "jid.*<your-jail>"

A VNET jail has its own fully independent network stack (its own interfaces, routing table, firewall rules); a non-VNET jail shares the host’s network stack directly. Networking problems in each case have different causes, so confirming which type you’re actually running is the first branch point.

Step 2: for VNET jails, check the epair interface pair

VNET jails typically connect to the host via an epair — a virtual Ethernet cable with one end in the host and one end inside the jail:

ifconfig | grep epair
jexec <jail-name> ifconfig

Confirm both ends of the epair exist, are up, and that the jail-side end (epair1b, commonly) actually got assigned into the jail rather than staying on the host.

Step 3: check that the host-side epair end is bridged correctly

ifconfig bridge0

The host-side epair end needs to be a member of a bridge that also includes the host’s real network interface, for the jail to actually reach the outside network:

ifconfig bridge0 addm epair0a addm em0

A jail with a perfectly configured epair but no bridge membership on the host side is isolated from everything except the host itself.

Step 4: check the jail’s own IP configuration and default route

jexec <jail-name> ifconfig epair0b
jexec <jail-name> netstat -rn

A VNET jail needs its own IP address and default route configured inside the jail — these aren’t inherited from the host automatically, since the whole point of VNET is an independent network stack.

Step 5: check the host’s firewall isn’t blocking bridged traffic

pfctl -sr | grep bridge0

If pf is enabled on the host, rules scoped too narrowly to physical interfaces can silently drop traffic being bridged between the jail’s epair and the real network — worth checking explicitly rather than assuming jail traffic is exempt from host firewall rules.

Step 6: for non-VNET jails, check the shared-stack IP binding

jls

A non-VNET jail’s network problems are usually simpler: confirm the IP address assigned to the jail in jail.conf or via jls is actually correct, reachable from other hosts on the same segment, and not colliding with an address already in use elsewhere.

Why VNET vs. non-VNET is the essential first branch

Non-VNET jails share the host’s actual network stack, so their networking problems are usually IP/routing misconfigurations; VNET jails have a genuinely separate stack, so their problems more often involve the epair/bridge plumbing connecting that separate stack to the outside world. Troubleshooting a VNET jail’s connectivity as if it were sharing the host stack — or vice versa — leads directly to checking the wrong layer entirely.