Whoops! I quoted keyser in that big block of text above when I meant to quote part of the comment about wireshark/tcpdumping. It won't let me edit it anymore to fix it. Sorry for the misquote and excessive pings.

@Cabledude yeah the reverse proxy makes it easy for the ssl offload for sure. Use it myself for that reason.

@Gertjan Hi, thanks for your answer, I don´t see the wood because the many trees there! any and <other types> doesn´t make sense and some rules worked. I think the any and other types was the problem... And yes, EXTERN is an interface on that pfSense... ;)

Followed all of your suggestions and pfsense and my lan are working really well! Thanks for your suggestion and sticking with me on this. It really helped me out!

Shot in the dark, but you're probably also needing 55930 as the destination port, not the source port. You're welcome. We'll all be here if follow-up is needed as you make more progress.

@tinfoilmatt said in Something to be worried about? Block private networks from WAN block 192.168/16 (12004): The hunt for 192.168.131.0 continues. A futile exercise. Just disable this logging and be done. There's literally nothing to address here. Of course, you're right. It is more of a curiosity as @johnpoz said. And seeing all this prompted me to lock down my network more and reject any attempts to connect to it. Now I do like to look at logs periodically to see what my network is doing. There are things I learn from that (like these weird 192.168.131.junk). But my DHCP logs keeps logging dhcp6c failed connects even though I don't have DHCP6. I unchecked Allow DHCP6 under Advanced Networking. I tried to change IPV6 to None under Interface>WAN, but it won't let me change that while the interface is configured. Knowing my skills, I'd get completely locked out of my network and be unable to even ask for help if I started messing with that. I supposed I could try configuring the OPT and play with that one. I just wish there was a way to not log specific logs like the dhcp6c.

The fact that the transfer fails at almost exactly the same point and coincides with a 100% CPU spike and gateway latency increase makes me suspect the pfSense box itself rather than the VLANs or SMB connection. I’d check the pfSense CPU usage per process during the transfer rather than just the overall CPU graph. Since you’re also running pfBlocker, DNS, DHCP and WireGuard, one of those services could be contributing to the spike. It may also be worth temporarily disabling WireGuard and pfBlocker completely and testing a large transfer between two VLANs. I’d also try an iperf3 test between the VLANs. If iperf3 reproduces the CPU spike/drop, you can eliminate SMB as the cause and focus on packet processing, firewall rules, NIC drivers/offloading, or the hardware itself. If the issue consistently appears at the same transfer point, I’d definitely investigate what process is consuming CPU at that exact moment.

I just hit this issue with my interface groups. And thanks for the explanation. Opened a feature request here, if anyone wants to check. https://redmine.pfsense.org/issues/17001

@saidin said in TCP/IP Multicast Address Handling Remote DoS (spank.c): @dennypage well, in any case I need to identify a way to block this thing Before you can block anything, you need to understand what’s actually happening. The information at that link might sound good, but is rather meaningless (like an AI summary). 🫣 I would recommend capturing packets to determine what is actually happening. This is the only way to make an informed decision.

@Kilted1 General Questions is probably better.

@patient0 said in Difference between protocol IPv4 ANY and IPv4*?: Is that similar for you, if try to edit the rule? I can change the interface in this rule, it isn't greyed out. @johnpoz said in Difference between protocol IPv4 ANY and IPv4*?: But odd that they would show up different than normal any rule showing the * There is one difference in the last rule, the action is "Deny Both". [image: 1784187885878-pfsense-2026-07-16_09-44.png] @Bob.Dig thanks for the confirmation.

@valnar Considering that pfSense is just software on top of an open operating system, it's definitely feasible. It just depends on how much time & effort you're willing to put into it to create your solution yourself. Others have already mentioned Snort/Suricata which works but seems like overkill to me. I don't spend any time worrying about doorknob-rattlers. I trust my door is secure and locked.

@abarna said in pfsense windows defender: Does pfSense or any officially supported Netgate package provide a Microsoft-maintained dynamic URL/FQDN feed for Defender Antivirus updates? That question needs the answer of another question : Does Microsoft published their IP (or host names) ? The only answer I've found : they have there own entire 'AS' just for them (millions of IPs) and at any time it could be 'any of these IPs'. The reason why they don't publish this info can be recapped in one word : security. Squid : I presume the update IP uses TLS with and the Microsoft server will impose 'SHTS' so a proxy will be a no-go. After all, if Windows Updates can get proxied this will open the door for huge security issues. Btw : There are, afaik, Windows products that can 'cache' official Microsoft Updates. As always : I hope to be wrong of course ^^ Why do you want to 'filter' this traffic ? @abarna said in pfsense windows defender: llow Microsoft Defender update traffic based on application/service identity rather than destination FQDNs What does Squid see ? A Ethernet packet = a packet header and the data payload. The packet header contain info like source destination IP, source destination port, some flags and protocol uses, a time stamp and a packet sequence number. The notion of an 'app' is buried in the data, and the data is TLS (or 'better') encrypted, so Squid can't see/use it

@Gertjan said in what is the correct way to do DNS rules?: Don't forget to give your pfSense several Tera bytes drive space to log .... ^^ Yeah pfsense is definitely not a logging solution or SIEM. That is always different hardware. :) We're hijacking the hell out of the OP. Block all DNS related ports. Block all known IPs that do DNS on other ports. Log it independently ( not a pfsense function ) Add any logged traffic to blocked IPs. Maybe that clustef*** list of safe dns spams will help some. Know that this is 2026...a perimeter gateway is not going to protect you completely. It isn't wrong...it just isn't enough.

@byakka You were correct. The solution for mixed aliases is Enter all FQDN in "IPv4 Source Definitions" as separate Format: Whois, State: On. As described in the OP Enter all explicit IPv4 addresses in the "IPv4 Custom_List" custom list section. Ensure "Enable Domain/AS" is not checked.

A quick note on "allowing the internet": in general that can be done with a single rule. For example: pass on <lan interface> from <lan subnet> to ! _reserved46_ [image: 1783030751596-e629fcd4-c7c8-463a-adc5-c630332de2c0-image.png]

@Gertjan Thanks. Only way I would ever access pfSense remotely is via a VPN. GUI port is NOT exposed to internet. I was more puzzled on both GUI's using 8443. I will change my pfSense port to something else. Thanks everyone.