New log type entry?

[Bob.Dig]

@stephenw10 You mean a rule without a description? And what anchors? I can't follow. I am just a GUI-user.

[stephenw10]

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.

[marcosm]

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.

[Bob.Dig]

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

[Bob.Dig]

said in New log type entry?:

Looks like having a block rule on that interface is "fixing" it for my eyes.

That turned out not to be the case, still seeing these log entries.

[stephenw10]

Ok and your ruleset doesn't have any lines that don't have an ridentifier?

For example this test box doesn't have any that might block traffic:

[2.8.1-RELEASE][admin@t70.stevew.lan]/root: pfctl -sr | grep -v ridentifier
scrub from any to <vpn_networks> fragment no reassemble
scrub from <vpn_networks> to any fragment no reassemble
scrub on igb0 inet all fragment reassemble
scrub on igb0 inet6 all fragment reassemble
scrub on igb1 inet all fragment reassemble
scrub on igb1 inet6 all fragment reassemble
scrub on igb3 inet all fragment reassemble
scrub on igb3 inet6 all fragment reassemble
scrub on igb0.229 inet all fragment reassemble
scrub on igb0.229 inet6 all fragment reassemble
scrub on ipsec1 inet all fragment reassemble
scrub on ipsec1 inet6 all fragment reassemble
scrub on igb1.50 inet all fragment reassemble
scrub on igb1.50 inet6 all fragment reassemble
anchor "openvpn/*" all
anchor "ipsec/*" all
anchor "userrules/*" all
anchor "tftp-proxy/*" all
anchor "miniupnpd" all

[Bob.Dig]

@stephenw10 There are two on that interface.

scrub on hn2.2166 inet all fragment reassemble
scrub on hn2.2166 inet6 all fragment reassemble

And here is the whole output.

Spoiler

[25.07.1-RELEASE][admin@pfSense.internal]/root: pfctl -sr | grep -v ridentifier
scrub from any to <vpn_networks> max-mss 1400 fragment no reassemble
scrub from <vpn_networks> to any max-mss 1400 fragment no reassemble
scrub on hn0.2 inet all fragment reassemble
scrub on hn0.2 inet6 all fragment reassemble
scrub on hn0.4 inet all fragment reassemble
scrub on hn0.4 inet6 all fragment reassemble
scrub on hn2.2170 inet all fragment reassemble
scrub on hn2.2170 inet6 all fragment reassemble
scrub on hn2.2173 inet all fragment reassemble
scrub on hn2.2173 inet6 all fragment reassemble
scrub on hn2.2174 inet all fragment reassemble
scrub on hn2.2174 inet6 all fragment reassemble
scrub on hn2.2167 inet all fragment reassemble
scrub on hn2.2167 inet6 all fragment reassemble
scrub on hn2.2169 inet all fragment reassemble
scrub on hn2.2169 inet6 all fragment reassemble
scrub on hn2.2163 inet all fragment reassemble
scrub on hn2.2163 inet6 all fragment reassemble
scrub on hn0.3 inet all fragment reassemble
scrub on hn0.3 inet6 all fragment reassemble
scrub on hn2.2162 inet all fragment reassemble
scrub on hn2.2162 inet6 all fragment reassemble
scrub on hn0.5 inet all fragment reassemble
scrub on hn0.5 inet6 all fragment reassemble
scrub on hn2.2161 inet all fragment reassemble
scrub on hn2.2161 inet6 all fragment reassemble
scrub on tun_wg1 inet all max-mss 1240 fragment reassemble
scrub on tun_wg1 inet6 all max-mss 1220 fragment reassemble
scrub on tun_wg4 inet all max-mss 1380 fragment reassemble
scrub on tun_wg4 inet6 all max-mss 1360 fragment reassemble
scrub on tun_wg2 inet all max-mss 1380 fragment reassemble
scrub on tun_wg2 inet6 all max-mss 1360 fragment reassemble
scrub on hn1.2172 inet all fragment reassemble
scrub on hn1.2172 inet6 all fragment reassemble
scrub on hn2.70 inet all max-mss 1452 fragment reassemble
scrub on hn2.70 inet6 all max-mss 1432 fragment reassemble
scrub on tun_wg5 inet all max-mss 1380 fragment reassemble
scrub on tun_wg5 inet6 all max-mss 1360 fragment reassemble
scrub on tun_wg6 inet all max-mss 1240 fragment reassemble
scrub on tun_wg6 inet6 all max-mss 1220 fragment reassemble
scrub on hn1 inet all fragment reassemble
scrub on hn1 inet6 all fragment reassemble
scrub on hn2 inet all fragment reassemble
scrub on hn2 inet6 all fragment reassemble
scrub on hn2.2166 inet all fragment reassemble
scrub on hn2.2166 inet6 all fragment reassemble
scrub on hn2.71 inet all max-mss 1452 fragment reassemble
scrub on hn2.71 inet6 all max-mss 1432 fragment reassemble
scrub on hn2.2160 inet all fragment reassemble
scrub on hn2.2160 inet6 all fragment reassemble
scrub on hn0 inet all fragment reassemble
scrub on hn0 inet6 all fragment reassemble
scrub on hn2.2164 inet all fragment reassemble
scrub on hn2.2164 inet6 all fragment reassemble
scrub on tun_wg7 inet all max-mss 1380 fragment reassemble
scrub on tun_wg7 inet6 all max-mss 1360 fragment reassemble
scrub on hn2.72 inet all max-mss 1452 fragment reassemble
scrub on hn2.72 inet6 all max-mss 1432 fragment reassemble
scrub on tun_wg9 inet all max-mss 1380 fragment reassemble
scrub on tun_wg9 inet6 all max-mss 1360 fragment reassemble
scrub on hn2.2171 inet all fragment reassemble
scrub on hn2.2171 inet6 all fragment reassemble
anchor "openvpn/*" all
anchor "ipsec/*" all
anchor "userrules/*" all
anchor "tftp-proxy/*" all

[stephenw10]

Hmm, nothing there then. It pretty much has to be some dynamic rule change.... Hmm

[Bob.Dig]

Despite unticking "Packets blocked due to IP options" in the log-settings, those entries still come up.

[Gertjan]

@marcosm said in New log type entry?:

run "pfSsh.php playback pfanchordrill" for that

Not related, just for the the record :
pfanchordrill breaks when the captive portal is used :

[25.07.1-RELEASE][root@pfSense.bhf.tld]/root: pfSsh.php playback pfanchordrill

cpzoneid_2_allowedhosts rules/nat contents:

hostname_0 rules/nat contents:
pfctl: DIOCGETRULES: Invalid argument
pfctl: DIOCGETRULES: Invalid argument

Looks like 'pf' and 'pfctl' don't speak same language ^^

[stephenw10]

@Gertjan Hmm, when you see that it's almost always because it's pulled in something newer. Or not rebooted after an upgrade. So some mismatch between kernel and world. But let me check....

Edit: Not seeing that here:

[25.07.1-RELEASE][admin@6100.stevew.lan]/root: pfSsh.php playback pfanchordrill

cpzoneid_2_allowedhosts rules/nat contents:

cpzoneid_2_auth rules/nat contents:

cpzoneid_2_passthrumac rules/nat contents:

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:

[tinfoilmatt]

@Bob.Dig said in New log type entry?:

There is no rule at all on that interface.

This feels like a clue. What is that 'interface'—PRIVVPN—then? What's it do? What's it for? What kind of traffic is supposed to be passing it, from and to where?

Notice in OP how the oldest packet is apparently a TCP packet without any flag set, no source/destination ports logged? But then the next packet is an ACK in the same direction, ostensibly from a webserver, and this time with logged ports?

And this...

Spoiler

[25.07.1-RELEASE][admin@pfSense.internal]/root: pfctl -sr | grep -v ridentifier
scrub from any to <vpn_networks> max-mss 1400 fragment no reassemble
scrub from <vpn_networks> to any max-mss 1400 fragment no reassemble
scrub on hn0.2 inet all fragment reassemble
scrub on hn0.2 inet6 all fragment reassemble
scrub on hn0.4 inet all fragment reassemble
scrub on hn0.4 inet6 all fragment reassemble
scrub on hn2.2170 inet all fragment reassemble
scrub on hn2.2170 inet6 all fragment reassemble
scrub on hn2.2173 inet all fragment reassemble
scrub on hn2.2173 inet6 all fragment reassemble
scrub on hn2.2174 inet all fragment reassemble
scrub on hn2.2174 inet6 all fragment reassemble
scrub on hn2.2167 inet all fragment reassemble
scrub on hn2.2167 inet6 all fragment reassemble
scrub on hn2.2169 inet all fragment reassemble
scrub on hn2.2169 inet6 all fragment reassemble
scrub on hn2.2163 inet all fragment reassemble
scrub on hn2.2163 inet6 all fragment reassemble
scrub on hn0.3 inet all fragment reassemble
scrub on hn0.3 inet6 all fragment reassemble
scrub on hn2.2162 inet all fragment reassemble
scrub on hn2.2162 inet6 all fragment reassemble
scrub on hn0.5 inet all fragment reassemble
scrub on hn0.5 inet6 all fragment reassemble
scrub on hn2.2161 inet all fragment reassemble
scrub on hn2.2161 inet6 all fragment reassemble
scrub on tun_wg1 inet all max-mss 1240 fragment reassemble
scrub on tun_wg1 inet6 all max-mss 1220 fragment reassemble
scrub on tun_wg4 inet all max-mss 1380 fragment reassemble
scrub on tun_wg4 inet6 all max-mss 1360 fragment reassemble
scrub on tun_wg2 inet all max-mss 1380 fragment reassemble
scrub on tun_wg2 inet6 all max-mss 1360 fragment reassemble
scrub on hn1.2172 inet all fragment reassemble
scrub on hn1.2172 inet6 all fragment reassemble
scrub on hn2.70 inet all max-mss 1452 fragment reassemble
scrub on hn2.70 inet6 all max-mss 1432 fragment reassemble
scrub on tun_wg5 inet all max-mss 1380 fragment reassemble
scrub on tun_wg5 inet6 all max-mss 1360 fragment reassemble
scrub on tun_wg6 inet all max-mss 1240 fragment reassemble
scrub on tun_wg6 inet6 all max-mss 1220 fragment reassemble
scrub on hn1 inet all fragment reassemble
scrub on hn1 inet6 all fragment reassemble
scrub on hn2 inet all fragment reassemble
scrub on hn2 inet6 all fragment reassemble
scrub on hn2.2166 inet all fragment reassemble
scrub on hn2.2166 inet6 all fragment reassemble
scrub on hn2.71 inet all max-mss 1452 fragment reassemble
scrub on hn2.71 inet6 all max-mss 1432 fragment reassemble
scrub on hn2.2160 inet all fragment reassemble
scrub on hn2.2160 inet6 all fragment reassemble
scrub on hn0 inet all fragment reassemble
scrub on hn0 inet6 all fragment reassemble
scrub on hn2.2164 inet all fragment reassemble
scrub on hn2.2164 inet6 all fragment reassemble
scrub on tun_wg7 inet all max-mss 1380 fragment reassemble
scrub on tun_wg7 inet6 all max-mss 1360 fragment reassemble
scrub on hn2.72 inet all max-mss 1452 fragment reassemble
scrub on hn2.72 inet6 all max-mss 1432 fragment reassemble
scrub on tun_wg9 inet all max-mss 1380 fragment reassemble
scrub on tun_wg9 inet6 all max-mss 1360 fragment reassemble
scrub on hn2.2171 inet all fragment reassemble
scrub on hn2.2171 inet6 all fragment reassemble
anchor "openvpn/*" all
anchor "ipsec/*" all
anchor "userrules/*" all
anchor "tftp-proxy/*" all

...feels like a mess. But it does give some insight into this system's configuration. Definitely makes it all less of a wonder.

[Bob.Dig]

@tinfoilmatt said in New log type entry?:

...feels like a mess.

What is the output if you run this command...

[tinfoilmatt]

@Bob.Dig

[2.8.1-RELEASE][admin@edge]/root: pfctl -sr | grep -v ridentifier
scrub from any to <vpn_networks> no-df fragment reassemble
scrub from <vpn_networks> to any no-df fragment reassemble
scrub on ix0 inet all no-df random-id fragment reassemble
scrub on ix0 inet6 all no-df random-id fragment reassemble
scrub on ix1 inet all no-df random-id fragment reassemble
scrub on ix1 inet6 all no-df random-id fragment reassemble
scrub on ovpnc4 inet all no-df random-id fragment reassemble
scrub on ovpnc4 inet6 all no-df random-id fragment reassemble
anchor "openvpn/*" all
anchor "ipsec/*" all
anchor "userrules/*" all
anchor "tftp-proxy/*" all

[Gertjan]

@stephenw10 said in New log type entry?:

when you see that it's almost always because it's pulled in something newer.

Noop. I should be on 'Release', not RC or beta.

I'm, imho, on a rock solid 25.07.1. I saw the same thing happening on (several ?) versions before.
I've installed '25.07.1' clean and it was on of the first things I've tested.
I've written about it in the past, in the captive portal forum (I'll look it up : edit : here it is).

I use(d) this : Troubleshooting Captive Portal.

Even when I de activate the captive portal, I'll keep seeing this :

[25.07.1-RELEASE][root@pfSense.bhf.tld]/root: pfSsh.php playback pfanchordrill

cpzoneid_2_allowedhosts rules/nat contents:
pfctl: DIOCGETETHRULES: No such file or directory

hostname_0 rules/nat contents:
pfctl: DIOCGETRULES: Invalid argument
pfctl: DIOCGETRULES: Invalid argument

If I recall well, restarting pfSense without the portal will solve the issue.
Re activating the portal will bring the issue back.

dit : Bob.dig, sorry for polluting your post.

[Bob.Dig]

@tinfoilmatt said in New log type entry?:

But it does give some insight into this system's configuration. Definitely makes it all less of a wonder.

I changed mine, to look like yours. Let's see, if it has any positive impact.

Btw, your questions have been already answered here, it is a WAN-type interface and with that, it can have no rules and be perfectly fine.

[tinfoilmatt]

@Bob.Dig

[in New log type entry?:]

Notice in OP how the oldest packet is apparently a TCP packet without any flag set, no source/destination ports logged? But then the next packet is an ACK in the same direction, ostensibly from a webserver, and this time with logged ports?

Any thoughts provoked there? I don't see that as having been addressed anywhere.

All due politeness—but a jacked-up system has the potential to 'trigger' jacked-up logging...

[tinfoilmatt]

@Bob.Dig said in New log type entry?:

I changed mine to look like yours.

And this wouldn't seem feasible, so I'm not sure what you would've changed.

[stephenw10]

@tinfoilmatt said in New log type entry?:

...feels like a mess.

There are a lot of interfaces but that all looks like expected output.

[stephenw10]

@Gertjan said in New log type entry?:

hostname_0

What is hostname_0 in that context? I'll try to replicate with some clients on it....