@johnpoz THANKS for the detailed respone, my rounter fw it to another router that fw it to a web server I do not see the traffic in the internal router I see the rule on the external router that say it block the traffic , so I do not think it passed the fw agree I do not understand why I see access denied I used edge and chrome (on windows, and chrome on android phone) I do have pfblockgerNG on, but dont think its involved, it is blocking mainly other countries

@eeebbune System > Routing > Gateways has a column for Monitoring IP. It defaults to the WAN gateway. If you change it to another IP like 8.8.8.8 then a static route is created for 8.8.8.8 to only use that WAN. (see Diagnostics > Routes) If that WAN is down then you can't get to 8.8.8.8. Because if pfSense could get to it, then it wouldn't know that WAN as down.

@SteveITS They were not existing connections. In fact the tablets involved were just powered on and connected to the existing WiFi network with the existing firewall rules. It is just that the rules had mysteriously vanished(or anyhow that is exactly how it behaved).

figured it out, it looks like HAproxy is not letting me edit some system setting as when i log in with ip address all works as it should could it be my certificates?

@luckman212 said in IGMP IPV4 endless log-messages / rules not working :(: I assume Local is an interface group you created? Yes, sorry I didn't point that out. Yes, I use a "Local" group for controlling a bunch of stuff such as ICMP, IGMP, DNS, NTP, etc. Btw, yes you are correct IGMP is only used for IPv4. It's a habit I guess (and a poor one at that) that I casually choose IPv4/IPv6. For IPv6, ICMP/MLD is what is actually used, but I believe a rule for this is not necessary because the MLD packets do not have the router alert bit set (at least on my Cisco switches, YMMV).

To filter incoming traffic by IP and URL on pfSense, use firewall rules for IP blocking and a proxy or web filter (like Squid) for URL control. pfSense handles IP filtering natively, but URL filtering requires extra tools. For consistent outbound IPs useful in more complex setups you can check here. LightningProxies offers IPv6 proxies with 2× /29 subnet pools, unlimited bandwidth and threads, HTTP/SOCKS5 support, sticky or rotating sessions, IP whitelisting, and global coverage.

I thought that issue is resolved, but I just started to get same error: ``` [15-Aug-2025 07:21:41 US/Eastern] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 20480 bytes) in /usr/local/bin/kea2unbound on line 528 [15-Aug-2025 07:21:50 US/Eastern] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 20480 bytes) in /usr/local/bin/kea2unbound on line 528e_text Note: pfSense is set to Python mode in DNS/pfBlocker.

@johnpoz Thank you for the hints. I used the command pfctl -sa to grab the complete rule set. There are currently no block rules for icmp traffic and the label "gateway monitoring" cannot be found. So the reboot must have cleared this rule, which seems to imply that it get dynamically generated. The next time this issue reoccurs, I will try the above command again to verify that the blocking rule is in the listing. Indeed, I use the cloudflare IPv6 DNS server address to verify that the IPv6 gateway is up. My internet provider (Xfinity in the US) changed their network early this year, and since then, their IPv6 gateways are not pingable anymore. So I had to choose another address based on recommendation from someone in previous thread on this message board. I do not have much experience with IPv6 either. I just set up the gateway because the internet provider is assigning both IPv4 and IPv6 addresses. If I were not a little OCD, I would perhaps ignore it. But understanding the issue would be useful for my education.

@Bob.Dig said in After upgrading to 25.07 (6100) Strange empty firewall rules blocking UDP / no port: @conover Probably the same way you do it for "the new" IGMP logs, you create a block rule if this should be blocked, it is blocked right now, and make it no-log. Good point - thanks (wasnt aware of the new "IGMP rules"). But the log for the blocked rules do not say for which UDP port(s) the blocking is.

@ChrisJenk It doesn't make much sense to me what you(?) wrote in the start post. So I am with @JKnott on this one, better do it right in the first place before others have to explain to you how to do it "the old way".

@pwood999 I will keep this advise in my parenting note pad and apply it in a couple years. I like it!

@SteveITS yes it look like, but I have actual filterdns log entries im my log.

@mcury I changed back to 389 and same problem now, BIND failed connection ok. I have configured 60-70 pfsense without any problem in LDAPS I have windows serevr 2025 and also disable LDAP required signing.

Thanks, that’s really useful! :) I’ve tried using aliases a few times before, but I’ll make an effort to use them more often. Just set one up for Spotify Premium https://seruapk.com/spotify/ now... :)

@GeorgeCZ58 Looks like a feature to me - once you reach so many interfaces/rows of them in the gui its better to switch over to a drop down..

@Fredish well where I would look is that rule @39 you didn't create.. So if I look in my rules. I don't show that specific number but same rid I see this rule. I am not using floating states. [24.11-RELEASE][admin@sg4860.home.arpa]/var/etc: cat /tmp/rules.debug | grep 1000003570 antispoof for $WLAN ridentifier 1000003570 If I then track that down with pfctl -vvsr I find rules like this.. here is some for vlans @98 block drop in on ! igb2.4 inet from 192.168.4.0/24 to any ridentifier 1000007770 @104 block drop in on ! igb2.6 inet from 192.168.6.0/24 to any ridentifier 1000008820 @110 block drop in on ! igb4.1011 inet from 10.1.1.0/24 to any ridentifier 1000009870 Which are exactly like the rule you showed your traffic matching on with the ! (not) statement and the network on that vlan. Here is the one for the rule that machines the same rid as yours @81 block drop in on ! igb2 inet from 192.168.2.0/24 to any ridentifier 1000003570 So from what you posted.. Like I said before you have source traffic hitting your vlan 20 interface that is not from the 10.1.20 network - in correctly isolated vlans this should never be possible. Could be issue with multihomed device sending its return traffic out different interface. Could be tagging issue in your switching infrastructure be that physical switching or virtual switches/port groups, etc. But normally it should not be possible for some different source IP to be inbound into a pfsense interface on a different network. With floating states pfsense is allowing this, when to be honest it shouldn't really - unless for some reason as they mention you have a asymmetrical because you have to for some reason?? The only time you should see different source IPs on an interface would be on a transit/connector network that you are routing downstream networks through. So I would look there - why is that traffic hitting your em0.20 interface when the source IP is not in the 10.1.20 network? if I were to guess I would assume something wrong in your virtual switching setup where tags are not being handled correctly.