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.

scandeny.jpg

@johnpoz This even does this with the newest CE edition inside of UTM virtualized environment outside of the 2100s

Screenshot 2025-07-17 at 10.15.51.png

It is not just the 2100s this is set up for standard stuff everything else works with it just the status page

Wel, really strange
I disabled the Allo VPN floating rule and restarted pfsense
Now, VPN works even with the block rule and without pass rule, as expected
Really strange that it needed a reboot and the logs I posted above

In general, as my friend said, seven troubles - one reset. The situation was corrected by reinstalling the system and restoring the configuration. This can be written down as a solution to the problem.

@detox you should be able to edit your first post and edit title with [solved] in the title, add tag.. If you can not - let me know and can do it for you. There might be some restrictions on rep ports or something - but you have 6, I would think that enough?

@rasputinthegreatest see my edit about devices sending it out even when they have an IP on the network - my directv appliance does that.. But once you have a mac should allow you to track it down. Especially if you have a smart switch and its wired. Where you can look at the mac address table.

If everything is working and you just don't like the noise in the logs, you can turn those off, either in log settings - I believe new 2.8 allows for not logging link local. Or you could setup a rule not to log it.

@John_McNoob

Got it working now :)

@Gertjan

I don't have the energy to verify why it's rejecting the gateway. Perhaps something has updated in the NAS (OMV) in the meantime. The important thing is that it works, thx :)

@AndyRH :

Many thanx to you. I've implemented your rules and they seem to work exactly as intended.
Most surprisingly for me, they do this without dedicated firewall rules.
Thumbs up!

Best regards

JD.

Well like I said I've tried to do that so.... I'm not sure. 😉

Does it work? I'd expect to see a load of errors when it creates the test config of there's a problem.

@SteveITS Thank you for the info ! I think I have a better grasp now on what my issue was. Since I disabled IGMP Snooping in the Unifi controller for my IOT net and associated VLANs I have not had any more notices in the firewall log (I still have the pass rules with log on, but nothing is showing in the firewall log, so I assume there is no more IGMP traffic. Cheers

@JonathanLee said in To Default Reject Or Block That is the Question.:

I wanted to share this with you incase you ever asked the question what the difference its between block or reject...

A block just drops the packet, without any other response. A reject sends an ICMP message back advising why. You want to use block on the WAN, so that the attacker has no confirmation there's something there. Use reject on the LAN, so that an issue can be identified.

Screenshot 2025-07-07 at 18.35.31.png

You know what it was I had it set to reject and not block HAHA I can't believe I didn't see that before, that is a Homer Simpson moment.

Screenshot 2025-07-07 at 18.38.12.png

This issue has since resolved itself though the root cause is unknown and there have been numerous changes made to the firewall between when it was last observed to not work vs. now when it is working.

@rasputinthegreatest normally hosting stuff on big cdn networks is not cheap - and would assume they do some vetting of what is being hosted/served. Not saying stuff can not be compromised - but seems unlikely some malware people would choose to host their crap there to be honest. While that cdn is not a global player to the likes of aws/azure or clouldflare, etc. They are not a ma and pop vps hoster ;)

Glad you got it figured out - and this thread might be very helpful for the next guy.