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

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.