pfSense VM on Proxmox (virtio) does not recover WAN after cable modem restart – better way than cron + pfSctl?

tomashk

Hi all,

pfSense 2.8.1 CE is running as a VM on Proxmox VE 9.1.4. The WAN and LAN of the pfSense VM use virtio network interfaces connected to Linux bridges on the Proxmox host. PCI passthrough is not an option in this setup.

When the cable modem is power-cycled (or reboots for any other reason), the physical NIC on the Proxmox host correctly reports link down / up in syslog, for example:

Dec 29 13:06:51 pve-gk8p kernel: igc 0000:02:00.0 nic0: NIC Link is Down
Dec 29 13:06:51 pve-gk8p kernel: vmbr0: port 1(nic0) entered disabled state
Dec 29 13:07:37 pve-gk8p kernel: igc 0000:02:00.0 nic0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Dec 29 13:07:37 pve-gk8p kernel: vmbr0: port 1(nic0) entered blocking state
Dec 29 13:07:37 pve-gk8p kernel: vmbr0: port 1(nic0) entered forwarding state
Dec 29 13:07:59 pve-gk8p kernel: igc 0000:02:00.0 nic0: NIC Link is Down
Dec 29 13:07:59 pve-gk8p kernel: vmbr0: port 1(nic0) entered disabled state
Dec 29 13:08:02 pve-gk8p kernel: igc 0000:02:00.0 nic0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Dec 29 13:08:02 pve-gk8p kernel: vmbr0: port 1(nic0) entered blocking state
Dec 29 13:08:02 pve-gk8p kernel: vmbr0: port 1(nic0) entered forwarding state

However, this link flap does not propagate as an interface down/up event into the pfSense VM’s WAN interface (virtio). From pfSense’s point of view the interface never actually goes down, so it does not properly recover the WAN connectivity after the modem comes back. The gateway status then shows 100% packet loss for the WAN gateway, but nothing automatically triggers to restore connectivity.

By searching around, a workaround was found: running

/usr/local/sbin/pfSctl -c 'interface reload wan'

inside pfSense immediately restores the connection (WAN comes back online, traffic flows again).

Because of that, a small script has been installed inside pfSense at /usr/local/bin/wan-check.sh:

#!/bin/sh
HOME=/root
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
export HOME PATH

GW=$(/usr/local/sbin/pfSsh.php playback gatewaystatus | grep "WAN_DHCP")
LOSS=$(echo "$GW" | awk '{print $6}' | sed 's/%//' | cut -d. -f1)
STATUS=$(echo "$GW" | awk '{print $7}')

if ([ ! -z "$LOSS" ] && [ "$LOSS" -gt 90 ]) || ([ "$STATUS" != "online" ] && [ ! -z "$STATUS" ]); then
    logger "WAN: Loss=${LOSS}% Status=${STATUS} - reloading"
    /usr/local/sbin/pfSctl -c 'interface reload wan'
# else
#    logger "WAN: Loss=${LOSS}% Status=${STATUS} - OK"
fi

Cron runs this every 5 minutes. In practice this has been working reliably so far, but it feels like a workaround rather than the "right" way to handle the problem.

The questions are:

Is there a built-in or recommended pfSense mechanism to handle this situation (gateway shows 100% loss after upstream modem reboot, but interface itself never went link-down because of virtualization / virtio), so that a cron script is not needed?
Is pfSctl -c 'interface reload wan' considered a safe and correct way to programmatically “kick” the WAN from CLI on 2.8.1 CE, or is there a more appropriate script or rc hook to call instead (for example an rc.* script that better mirrors what the GUI does when toggling / renewing the WAN interface)?
On the Proxmox side: is there any simple setting or best practice (still using virtio, no passthrough) that would allow the link state change of the physical NIC / bridge to be reflected to the pfSense VM’s virtio interface, so that pfSense would see a proper down/up event and handle everything by itself?

tomashk

Since I haven't received any feedback yet, here's a quick update and a more specific question.

The cron script using pfSctl -c 'interface reload wan' works reliably and restores connectivity every time the modem reboots.

Question: Does pfSctl -c 'interface reload wan' do the same cleanup (like clearing firewall states, resetting connections) as when pfSense detects a real physical link down/up event?

I want to confirm this is safe for long-term use and won't deal any strange problems.