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.

Could you simply put the API service on a different port to the public https, and then filter by source IP & destination port ?

@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.

I managed to resolve my above issue and for anyone ending up with the same question: My issue was caused because of a colleague who added a floating rule, rejecting traffic coming form another alias with logging disabled on that rule. Unfortunately that alias contained a different FQDN that resolved to the same IP of the removed FQDN. What is the important lesson here: Apparently the PF box handles floating rules AFTER interface rules. And since logging of that floating rule was disabled, the firewall log logged the allowed traffic from the interface rule, but blocked the traffic afterwards based on the floating rule with no logging! You end up seeing an allow in your log, but it is blocked in the end! This must be a culprit some else will face one day or another :)

@greatbush well you can ping other interfaces on pfsense, just not the 172.16.64 one. At a loss.. You have no floating rules.. And looks like your rule triggered and state are created there in that top rule you posted trying to talk to it. You have no floating rules - and no current vpn tunnels.. Yeah at a loss to what would cause that. Can you talk to any of the other 172.16.x interfaces you have via the route table you sent..

@aaronouthier There was a bug in 24.3/11 where deleting multiple rules would reorder them. There’s a patch. But otherwise no it’s not normal at a reboot. Maybe compare config files before and after?

@rasputinthegreatest well blocking and not log would just be any any udp to that ff0e::c address or port 1900 anything, etc. And don't have it log. As to the scanners - that is a pfblocker alias I have.. And put that in a floating rule. [image: 1752953863201-scandeny.jpg]