New log type entry?

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

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

tinfoilmatt

@stephenw10 If by "interfaces" you mean 'four virtualized interfaces, some outrageous number of virtual sub-virtualized interfaces, and a buncha WireGuard sprinkled in'—sure.

stephenw10

Ha, well levels of outrage may vary!

tinfoilmatt

Hey, I wouldn't have even chimed in if not for the incessant...

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

...insinuation...

I hope you guys will find the secret rule.

...that...

those entries still come up.

...there's some kind of development issue here. Outrageous indeed.

Gertjan

@stephenw10 said in New log type entry?:

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

See here : pfSsh.php playback pfanchordrill (when portal is active) - let's continue over there.