@stephenw10 I think they’re responding to me re the new HTTP header alerts. I wasn’t intending to hijack the thread, just say to watch out for them, too.
My overall point was to “yes and” the topic because normally one does not need to watch for excessive blocking with a Suricata upgrade. I would guess something in detection changed and/or new rules are triggering often.
To answer your question it’s a lot of connections to (and also from as I recall) the web servers. Like 10x normal blocking, without actually counting.
@marcosm I may indeed have reverted the patch and therefore introduced the bug. That would explain why others have not come across this as an issue.
I know that I "cleaned up" a few things recently and one of them was to delete the patch. I bet I hit Revert prior to also hitting Delete.
Odd that uninstalling acme and then reinstalling it didn't seem to fix it but reinstalling the patch did the trick.
Much appreciate your help.
What are you doing that triggers that error?
Selecting an interface in the gui traceroute only selects the source address. Normally on a WAN that will force traffic via that WANs gateway. But if there's no gateway set it will be routed using the system routing table like any other traffic.
[image: 1774023250262-3812c97f-0c8a-4078-b7e6-d1b800fe1a1a-image.png]
This happens randomly on every boot or CARP failover. Right now it affects the IPv4 WAN, but it could be any of the interfaces listed. Sometimes only one comes up. Sometimes all of them come up... I honestly don't know. I even installed OpenWrt, and it just works, so this is clearly not an ISP or upstream router issue.
pfSense is clearly misbehaving here.
It sounds like some of these things could have already been resolved upstream. Testing on something recent, preferably 26.03, would help reduce scope and help towards resolution.
@netblues said in pfSense VM on Proxmox: PPPoE only works when parent NIC is PCI passthrough — virtual NIC breaks LAN→WAN traffic:
@yon-0 Your issue is different.
Icmp always worked
26.03 fixes the original issue.
Have you tried with minimum configuration, after factory?
LAN to WAN icmp can't work.
Presumably when it's showing packet loss while the gateway is responsive, that means the traffic is either being blocked or not going out the right interface. The output of pfctl - vvss and pfctl - vsr should help narrow that down along with some pcaps.
@marcosm said in openvpn MTU bug:
Clients need the additional option to ignore the MTU pulled from the server. I'll add this so it's done automatically. For now you can add this to the custom options:
pull-filter ignore "tun-mtu"
Also note that MSS is calculated automatically on that page. So if you want the correct MSS based on a 1440 MTU then set the MSS value on that page to 1440 as well.
As for why fe80 addresses are the same it's because that's not a conflict. Those are link-local addresses and would require the scope in addition to the address (e.g. fe80::1%vtnet1).
pull-filter ignore "tun-mtu" this is work.
When I returned to edit, it showed a misalignment.
[image: 1771065856084-7116c286-7d1c-40ce-999a-befbe690aae5-image.png]
This is what fixed it for me in Pfsense Plus v25.11:
System->Advanced->Networking
In the section:
[Network Interfaces]
Check the following boxes:
Hardware TCP Segmentation Offloading
and
Hardware Large Receive Offloading
(Save and reboot Pfsense)
@stephenw10 Yes, the ifconfig gif0 down was just temporary, ran from ssh during the upgrade so it could complete. After reboot the v6 tunnel came up normally and is working fine. This includes pkg ... commands, menu option 13, System > Update etc.
Copyright 2026 Rubicon Communications LLC (Netgate). All rights reserved.
