@jimp Ok , thanks)))

@pfGeorge So what? What should I do or not do? Update something somewhere or just wait?

Thanks for following up. Good result!

The driver firmware loading issue is not fixed in 2.8.1. It's still broken upstream AFAIK. You will still need to apply one of the workarounds.

@Said.Fathy , Hi Said .. I'd strongly recommend Lawrence Systems' youtube channel... it's the best as far as pfsense is concerned.. from beginner to pro https://www.youtube.com/@LAWRENCESYSTEMS

@icoso said in Snort Alert list explanation: If I only run it on the LAN ports wouldn't that only prevent my users from going outbound to certain IP's? I think you're misunderstanding how it works. In legacy mode it will check for "bad" packets going past the router, and add the "bad" IP to a table/alias, and the firewall will block packets to/from that table. It is not directional in the sense of "it's on LAN so only watches outbound." Running it on LAN also identifies which internal device triggered the rule because otherwise on WAN it is after NAT, since it's outside the firewall. You can run it on WAN, sure. Some do if they have a lot of internal interfaces and don't want that many Snort/Suricata processes running. It's a tradeoff of "scanning packets that will never actually arrive" vs convenience/RAM usage. Here is the setting I mentioned in Suricata; the packages are similar to maybe Snort has it also: [image: 1757427238489-8223c7ca-ba6c-4503-8668-2b7c03e597ef-image.png] However, on the Snort interface settings click the View List button by "IP Pass List" and you'll see which IPs are ignored by default.

@Gertjan I did/do what you've described - and I only use IPv4 so don't even have to worry about DUIDs - and it doesn't work. It's rock solid at being buggy/broken, yes. If it were only me....sure, that could be my issue, but I'm not alone here with seeing the same problem. See my linked post - I showed you that the Kea DHCP process is doing the wrong thing via packet capture. There's no discernable reason why it's doing the wrong thing, it just does. Switch back to ISC and instantly all problems resolved. If you can tell me how I can figure out how/why it's broken, I'm listening.

@Luca-De-Andreis Hello, i have the same problem look here: https://forum.netgate.com/topic/198723/after-restart-unbound-dns-resolver-don-t-work/3?_=1757403706907

@SteveITS said in VLAN connectivity broken after upgrade to 2.8.1-RELEASE: Sure you don’t have asymmetric routing? You're absolutely right — the current setup does involve asymmetric routing. The state policy does positively influence the firewall's behavior, though it’s not a decisive factor. I had assumed that if one interface with asymmetric routing functions correctly, the others would follow suit. However, that’s not the case — only one interface appears to affect the behavior. In any case, this gives me confidence that the firewall will operate as expected once the VM is shut down. Fingers crossed for a smooth transition!

@stephenw10 Yeah I am not sure what went wrong originally but glad it is working now!

Yes please. Costs and timeline to run this as a standalone controller.

I think I just figured it out. Services > DHCP > ServerSettings Code: { "option-def": [ { "space": "dhcp4", "name": "vlan-id", "code": 132, "type": "uint32" } ] } Then hop over to the interface, in my case: PHLAN { "option-data": [ { "name": "vlan-id", "data": "10", "space": "dhcp4" } ] } Hope this helps someone! I don't have enough permissions apparently to delete my own post LOL.

Unlikely. The traffic handling for CP clients is identical in Plus.

If you think ACB was configured I can check for recent backups if you send me the NDI of the failed 1100 in chat.

Dude.... I feel dumb. There's a "Remove Shaper" button RIGHT THERE! :-) Clicked it, rebooted and so far the error has not returned to my notifications area. I don't expect it to either, since all the lines about queues are gone from /tmp/rules.debug. Glad I came here. Thanks for hand-holding me along, @SteveITS.

PHP Errors: [08-Sep-2025 00:01:03 America/New_York] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 4096 bytes) in /usr/local/bin/kea2unbound on line 344 If you are using Kea, with DNS registration enabled, and pfBlocker with DNS-BL be sure to use Python mode to avoid the PHP memory limit. You can also increase the PHP max mem value in Sys > Adv > Misc. But that shouldn't be required if you're using Python mode.

Oh yes there certainly are many users running VMs as edge on all hypervisors. I just wouldn't myself.

@Cortexian is the Windows firewall disabled/configured? https://docs.netgate.com/pfsense/en/latest/troubleshooting/nat-port-forwards.html