Loss of forwarding on 26.7 with Suricata Netmap IPS on Proxmox/VirtIO

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guidelines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue
• AI tools were used to create at least part of the text submitted herewith.

If AI was used, please disclose:

• Model used: gpt5.6-sol(xhigh) agent + claude-opus-5(xhigh) reviewer
• Extent of AI involvement: Drafting and review from live system data and retained logs.

Describe the bug

After upgrading from 25.7.7_4 to 26.7.1_1, this firewall stopped forwarding twice while Suricata ran in Netmap IPS mode on VirtIO interfaces.

During both incidents, the guest console remained responsive. Proxmox showed a steady 26.5% CPU for the four-vCPU VM, about one core, while traffic fell to a few KB/s. The LAN address stopped answering and a forced reset restored service.

Both incidents followed repeated netmap_transmit vtnet0 full messages. These messages also occur while the firewall is healthy, so this is a correlation, not a reliable failure signature.

The last known good version is 25.7.7_4, with FreeBSD 14.3 and Suricata 8.0.2. Intermediate releases were installed during the same upgrade session and were not validated. There has been no further stall in two days on 26.7.3_8, but the Netmap messages continue.

To Reproduce

I have not tried to force the stall in production, but the Netmap messages reproduce with:

1. OPNsense as a four-vCPU Proxmox VM with VirtIO NICs.
2. Suricata Netmap IPS on vtnet0 plus two other internal interfaces. Hardware CRC, TSO and LRO are disabled globally.
3. Sustained traffic through vtnet0, seen with routed WireGuard traffic around 125 Mbit/s and HTTPS downloads around 120 to 230 Mbit/s.

Expected behavior

Forwarding should continue under sustained traffic without requiring a hard reset.

Describe alternatives you considered

After the last reset, I stopped Suricata and the transfer completed without another stall. This was not a controlled test, and it removes IPS. PCAP mode removes blocking. I do not know of a supported workaround that keeps IPS blocking.

Screenshots

Not applicable. No GUI condition or visual artifact is involved.

Relevant log files

Examples from 26.7.3_8 during healthy forwarding, duplicates removed:

2026-09-02T12:22:01+02:00 netmap_transmit vtnet0 full hwcur 163 hwtail 174 qlen 500

There was no panic or crash dump. Proxmox host logs showed no OOM, storage, I/O, QEMU or HA fault at the incident times.

Additional context

• 20 August: upgrade. 24 August: first incident. 28 August: recurrence during a large download. 31 August: upgrade to 26.7.3_8 and IPS restarted.
• opnsense/core#9001 is the closest symptomatically but uses different hardware and an older release. opnsense/core#10697 is a Proxmox/VirtIO forwarding issue on 26.7 with IDS/IPS disabled, so there may be a shared underlying cause.

Environment

• OPNsense 26.7.3_8; first observed bad 26.7.1_1; last known good 25.7.7_4
• FreeBSD 15.1-RELEASE-p3 amd64; Suricata 8.0.6 RELEASE, Netmap IPS
• Proxmox VE 9.2.3, host kernel 7.0.0-3-pve
• VM: 4 vCPU, 12 GiB RAM, VirtIO NICs, x86-64-v2-AES; IPS on three internal interfaces
• Hardware CRC, TSO and LRO disabled globally

Start by comparing forwarding and Netmap behavior between 25.7.7_4, 26.7.1_1, and 26.7.3_8 in the reported four-vCPU Proxmox/VirtIO setup, using the repeated netmap_transmit vtnet0 full messages as an entry point. Reproduce sustained traffic with Suricata Netmap IPS enabled and determine whether forwarding remains stable without a hard reset.