pfSense on Virtio: TCP Stalls Until Offload Is Off

A client reports that the tunnel connects, a ping answers, the login page loads, and the transfer then freezes at the same point on every attempt. That pattern already says a lot: reachability works and sustained throughput does not. Before opening the firewall, find out whether the VPN participates in the failure at all. Push large TCP through the same gateway with no tunnel in the path; if it freezes too, OpenVPN was never involved.

A pfSense guest using a virtio NIC has a very good reason to fail in exactly that shape.

Small Packets Pass, Bulk TCP Hangs

Handshakes, DNS replies and ICMP echoes are tiny and usually get through. Sustained transfers force the guest to segment, and segmentation is where a damaged offload path surfaces. The fault need not be symmetric: outbound may be clean while inbound drops, or the reverse, so a user can log in and then stall on the first big response. Because the same client works through another gateway, the newest component takes the blame.

So test the gateway without the tunnel. A LAN-to-WAN download large enough to run for a few seconds is sufficient, and it has to be done before any setting changes so the comparison afterwards means something.

What Offload Actually Promises

virtio is paravirtual: host and guest share the work, the host advertises checksum and segmentation capabilities, and it expects the guest to finish what it started. If the guest's stack does not do that, frames leave with incomplete checksums or are dropped by the host. An emulated E1000 offers a simpler, slower model in which the problem evaporates without a single pfSense change. Capability negotiation happens per device, which explains why one guest runs for months and its rebuilt twin fails on day one.

The negotiated set depends on the hypervisor version and the chosen NIC model, not only on the configuration you imported.

One Checkbox Keeps Virtio

In the pfSense UI, System then Advanced then Networking holds a checkbox named Disable hardware checksum offload. Setting it makes the guest compute checksums in software, matching what the FreeBSD stack behind pfSense expects from a paravirtual device. Two related options on the same page cover hardware TCP segmentation offload and hardware large receive offload. Reach for those when handshakes succeed but bulk transfers do not.

Leave the NIC as virtio while making the change. Switching to E1000 burns CPU on every packet for the VM's lifetime and conceals the configuration problem from whoever inherits the host, which is a worse trade than a slightly slower but predictable datapath.

Measure the Cost You Just Accepted

Software checksumming moves work into the guest, so take a throughput measurement afterwards rather than assuming it costs nothing. On a small VM the penalty is real, yet it is visible and stable, unlike a silent drop. Compare interface error counters and the guest's kernel log before and after. A hypervisor that filters the bridge is a separate fault with different evidence, and no offload flag will cure it.

Change one thing per test and write down the menu path, the box you ticked and the number you measured. Whoever faces the next rebuilt guest will want all three.

Other BSD-based firewalls expose an equivalent control under their own interface settings, so the reasoning travels even when the menu path does not.