Because traffic is routed to IPSec tunnel

@whanlon np - while it it seems to be only cosmetic, since it does send the reject.. I would think should be a simple fix.. But then again I might be just assuming its easy.. Lets hope it can make it into 25.11.1 or 26.03

@eeebbune Just one note for future. If you usged the wizard and your "LAN" is OPT1 you get thes "anti Lockdown" rule assigned to it. If you decide to do scenarion with BRG1 to have the IP address I would recommend you add a rules from Bridge Interface to firewall itself 22/443 and make sure its (any) direction: [image: 1768652882762-458236fa-0e1b-443c-8f9b-7ea63c21aecc-image.png] I was testing bits and move all rules to "floating" so its easier to see / manage. So I added int BRD1 subnet_brd1 to any (out only) and deleted the default any to any from Brd1 interface and that locked me out from accessing firewall. Currently I have this: [image: 1768652926701-9eefb8f5-c27a-4cad-a714-6c3d2cb94a62-image.png] and deleted all other rules from all other tabs (lan, vlan10, bridge0) and it still all works. Currently all these rules have "direction" any but I want to test bit more with just "out" and "in" - shame it does not show this on summary. Still learnign all this different aproaches and floating rules so maybe I misunderstood something but thought I will share just in case

@MP83 FWIW Netgate doesn't date stamp releases but the order can be seen in the left navigation pane of https://docs.netgate.com/pfsense/en/latest/releases/. 25.11 changed FreeBSD versions (to 16), presumably why the fix was included in this case. Edit: dates are on https://docs.netgate.com/pfsense/en/latest/releases/versions.html, d'oh, I knew that.

@johnpoz I set those in the past (long time ago) from the firewall logs because of the same behavior when they were getting blocked. I'll disable for now and see what happens.

@Uglybrian ff02::16 is multicast. FWIW we always disable logging for the default block rules, unless diagnosing something. There's a lot less noise, and disk writes.

@SteveITS said in Packet Loss and Connection Drops During Local VLAN File Transfers (High CPU): @keyser Wondering out loud, would a per-IP limiter at 90% or 80% or whatever help? Maybe, but I'm not inclined to implement that for various reasons

Huawei. I‘m with Netgate and Huawei-Support in contact.

@FrankZappa glad you finally got it sorted.. packet capture can be your best tool.. So you can for sure see what is happening, or not happening.

Forgot to add one more possibly useful data point. The problem user "rba" can successfully execute a command like: easyrule showblock lan There are no errors with this or with a command like easyrule unblock lan 192.168.1.72 ...as long as there are no entries. Once there is an easyrule entry, say for example a block placed by the root user, then I can only show the block, and running unblock as rba produces the same Fatal Error.

@johnpoz the only common package in use is System Patches, and there aren't any non-package-provided patches installed. I'll keep digging.

pfsense blocks 169.254.. every 1-5 seconds what is this ??? Your LAN firewall(s) rule : [image: 1766751831585-e03e851c-e449-4b30-89c3-567b387f8df0-image.png] Disregard the first two rules. The third rule is most probably the same as what you have : You inform with this rule pfSense, the firewall, that it should allow incoming traffic that has source IP that falls in the scope of "LAN Subnets". In your case, that everything from 192.168.100.2 to 192.168.100.254, or 192.168.100.0/255 As per your command, traffic that has a source like "169.254.1.1.1" isn't part of the 192.168.100.0/255, so ... the firewall will block this traffic. And lists it the the firewall log as blocked. The one and only question is, as said above : why does this LAN device use an AIPA or 169.254.x.x IP ? Most probably because the DHCP negotiation failed. In that case, most devices assign themselves a pretty useless 169.254.x.x IP - with one advantage : you know now that that device needs your assistance.

Just a small note that I've released v1.3.0 of stv, supporting the new pfctl output format of pfSense+ 25.11 and CE 2.9.0.

@carrzkiss do you have valid users in Singapore? If not block the whole range of their IPs. This is really easy to do with pfblocker. If all you want to do is some block lists of ips or ranges that you don't like what they are doing - that can be done with just the native alias lists functions built right into pfsense. But yeah that is a good start. Just put your bad list of ips either on the top of your wan interface rule set - before your allows for your port forwards. Or put such list in your floating tab. Unless your userbase is really global - its much easier to just use allow lists for the countries you want to allow. This can filter many many of the bad guys with 1 simple rule and filter list.

@lvrmsc I hear what you’re saying. “Without Quick checked, the rule will only take effect if no other rules match the packet,” which makes it seem like a pass rule would be required to set traffic shaping? Unless the docs should say match will take effect without quick? We have no routers on 25.11 yet to check.

@stephenw10 Yep that fixed it

Okay, I'm even more confused now. I changed IP range , just in case there's a zombie policy somewhere. (firewall is now 192.168.18.1, client in this case is 192.168.18.5. I'm now seeing states on the firewall, for this interface. I also enabled logging, and ran a packet capture. The firewall log shows regular traffic being allowed, based on the generous allow policy I have. [image: 1766011483918-screenshot-2025-12-17-165956.png] The packet capture shows a whole bunch of TCP retransmits, and unanswered SYNs. [image: 1766011544145-45f67d0d-d112-4f05-bf83-4fcb846e79eb-image.png] I tried a traceroute was suggested, and got timeouts after the firewall.[image: 1766011592684-screenshot-2025-12-17-162013.png] Lastly, a possible puzzle piece: I found an active but unused gateway, listing opt6 as the interface(!!). I tried disabling then deleting that gateway, but doing so did not seemingly affect the symptoms I'm seeing.

@01xd pretty sure syn floods are turned on in advanced setting of your incoming rule you would need turn on synproxy. Where are you testing from? if from the local side of your pfsense it would never see your wan rule that would be incoming into the wan.