New log type entry?
-
How old are those logs?
The most likely think is that the ruleset did change since those were created so it's failing to lookup the rule that triggered it.
You might be able to see it if you switch the log view to 'raw'.
-
@stephenw10 They are from the same day, might be the same hour. There is no way, that there was a rule by me. UPnP is disabled.
That interface is "housing" several gateways but there is no gateway set in that interface config. Outbound NAT is active on that interface.
-
Mmm, that doesn't mean it didn't reload in that time. Check the logs. Anything dynamic at all might cause that.
-
@stephenw10 Just triggered it again, no way that there is something happening (I can think of).
Oct 21 19:34:13 pfSense filterlog[33132]: 4294967295,,,0,hn2.2166,match,block,in,4,0x0,,56,40119,976,none,6,tcp,424,157.240.0.63,192.168.216.49, Oct 21 19:34:13 pfSense filterlog[33132]: 4294967295,,,0,hn2.2166,match,block,in,4,0x0,,56,56210,976,none,6,tcp,424,157.240.0.63,192.168.216.49,I see those since 25.07 but I think that there are more now.
-
Hmm, you must have something unusual in the ruleset. pfBlocker? Captive Portal perhaps?
-
@stephenw10 No Captive Portal and no pfBlocker rules on that interface and not updating anyway while I trigger this.
Unusual is my usual hardware, Hyper-V. But again, this came with 25.07. I will disable Sticky Connections to see if it makes a difference.
-
The filter log doesn't show a tracker ID so I would start by going through the loaded ruleset for rules without an ID (pfctl -sr) and see if there's a rule that could match. In some special cases rules without logging enabled can still trigger a log.
-
@marcosm Didn't see nothing. ^^
-
@marcosm said in New log type entry?:
In some special cases rules without logging enabled can still trigger a log
So if I create a block rule with no log and put it on that interface I am good, like with IGMP? Also I could send you the output, it is almost 400 lines though.
-
You can upload it as a txt file here: https://nc.netgate.com/nextcloud/s/D24QzpR5xeMAdFb
-
@stephenw10 Done.
Looks like having a block rule on that interface is "fixing" it for my eyes.
-
@Bob.Dig Yes, like with IP Options. It could also be useful to get a pcap of the dropped packet.
-
@marcosm said in New log type entry?:
It could also be useful to get a pcap of the dropped packet.
I will look into this tomorrow and upload it. 192.168.216.49 would be the destination IP and I would capture everything with this IP for some seconds.
-
A pcap on the external side there would see the traffic before the NAT translation so 192.168.216.49 would not be the destination at that point.
-
@stephenw10 On which interface should I capture, I thought on that where the log is from.
-
Yes you should pcap on the external interface but you will need to filter by something else because 192.168.216.49 won't be present on those packets at that point.
-
@stephenw10 said in New log type entry?:
you should pcap on the external interface
I filtered only for TCP. Sry for it being that big but I had no success provoking it with just light traffic... Included is the log entry and some pfctl -sr.
I hope you guys will find the secret rule. -
Thanks.
To be clear though do you have any rules in your ruleset that do not have an ridentifier value set?
Within the anchors maybe?
-
@stephenw10 You mean a rule without a description? And what anchors? I can't follow. I am just a GUI-user.
-
I mean in the output of
pfctl -sr. In your txt file that is grep'd for ridentifier lines only. A rule that doesn't have an identifier won't set it on the state and could produce logs like this.
