New log type entry?

tinfoilmatt

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