After Proxmox update: NAT/Firewall rules silently fail to load — ALTQ not supported on virtio (vtnet) WAN interface

killahop

Summary

After updating Proxmox (host reboot included), all LAN/VLAN clients lost internet
access, while pfSense itself could still ping out fine. No obvious errors in the
GUI. Root cause: an ALTQ Traffic Shaper configured on WAN/LAN was silently
breaking the entire ruleset load (including NAT), because the virtio (vtnet)
driver used for the WAN interface does not support ALTQ.

Environment

pfSense CE 2.9.0-RELEASE (amd64), FreeBSD 16.0-CURRENT
Proxmox VE 9.2.11
pfSense VM with 4x virtio NICs (WAN, LAN, and two VLAN-tagged interfaces)
WAN NIC: virtio, (vtnet1)

Symptoms

After a Proxmox host reboot (following an update), all clients on LAN and
additional VLANs/interfaces lost internet access completely.
pfSense itself (pinging from the firewall, e.g. via Dashboard/Diagnostics)
could reach the internet fine — DNS resolution and ICMP worked from pfSense's
own WAN IP.
No relevant errors visible in the normal firewall logs (Status > System Logs >
Firewall). Only "noise" like blocked IPv6 multicast (ff02::16) and normal
SSH bruteforce attempts on WAN.
Packet capture on WAN showed client traffic leaving the WAN interface with
the original private source IP (e.g. 192.168.x.x) instead of being
translated to the WAN address — i.e. outbound NAT was simply not happening
for any client traffic, while pfSense's own locally-generated traffic
(which doesn't need NAT) worked normally.
pfctl -s nat returned nothing — the NAT ruleset was completely empty
in the active pf engine, despite Firewall > NAT > Outbound showing correct
Hybrid NAT rules in the GUI.

Diagnosis steps

Verified Proxmox-side networking (bridges, VLAN tagging, physical links) —
all fine, no driver/link issues in dmesg.
Verified NAT Outbound config in GUI — rules were present and correct
(Hybrid mode, automatic rules covering all subnets).
Packet capture on WAN interface confirmed client packets leaving untranslated
(private source IPs on WAN) — meaning NAT wasn't being applied at all.
pfctl -s nat from Diagnostics > Command Prompt returned empty output,
confirming the NAT ruleset was not loaded into the running pf engine,
even though the GUI config was correct.
Ran /etc/rc.filter_configure manually to force a full rule regeneration
and reload, and captured the shell output. At the very end:

Loading filter rules
Setting up logging information
Setting up SCRUB information
There were error(s) loading the rules (pfctl: vtnet1: driver does not
support altq): pfctl: vtnet1: driver does not support altq - The line
in question reads [0]:

This was the smoking gun: pfSense generates NAT + filter + ALTQ rules as
a single ruleset and loads it with one pfctl call. Since the WAN
interface (vtnet1, virtio) doesn't support ALTQ, and there was a legacy
Traffic Shaper (Firewall > Shaper > Per Interface, with qACK/qDefault on
WAN and qLink/qACK on LAN) configured, the entire ruleset load aborted
— silently, as far as the GUI is concerned. This meant NAT and firewall
rules were never actually applied after the reboot, even though they were
correctly saved in the configuration and visible in the GUI.

Fix

Firewall > Traffic Shaper > Per Interface > Remove Shaper.
Force a filter/ruleset reload (Status > Filter Reload, or
/etc/rc.filter_configure from the command prompt).
Confirmed pfctl -s nat now returned the expected NAT rules.
Internet access restored immediately for all LAN/VLAN clients.

Why this is worth reporting

The failure mode is very misleading: pfSense itself stays online and can
reach the internet, which points troubleshooting away from NAT/ruleset
loading and toward routing/switching/driver issues at the Proxmox level.
The GUI gives no visible warning anywhere that the ruleset failed to
load — you only see it by manually running /etc/rc.filter_configure (or
equivalent) from the command line and reading the raw output, or by
checking pfctl -s nat directly.
This is likely to become more common as more people run pfSense on Proxmox
with virtio NICs, especially if they have any legacy ALTQ Traffic Shaper
config left over from before switching to virtio, or from an older setup
(e.g. previously using e1000 which does support ALTQ).

Suggestion

Would it be feasible for pfSense to either:

Detect ALTQ-incompatible interfaces and skip/warn instead of aborting the
entire ruleset load, or
Show a persistent, visible GUI warning/banner when the last filter reload
failed, rather than only logging it in a way that requires manually
running rc.filter_configure or checking pfctl to notice?

A single incompatible shaper queue silently taking down NAT + firewall rules
for the whole box (while leaving the WAN interface itself apparently healthy)
seems like a fairly serious failure mode to have no visible indicator for.

Happy to provide more details/logs if useful.

jimp

System > Advanced, Networking tab, check Enable ALTQ support for vtnet/hn NICs