New log type entry?
-
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. -
I didn't mean to leave the grep part in my previous example
. IIRC that won't show anchor rules so you can run "pfSsh.php playback pfanchordrill" for that. -
@marcosm said in New log type entry?:
pfSsh.php playback pfanchordrill
That lists no rules.
ipsec rules/nat contents: natearly rules/nat contents: natrules rules/nat contents: openvpn rules/nat contents: tftp-proxy rules/nat contents: userrules rules/nat contents:
