New log type entry?
-
@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: -
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.
-
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 -
@stephenw10 There are two on that interface.
scrub on hn2.2166 inet all fragment reassemble scrub on hn2.2166 inet6 all fragment reassembleAnd here is the whole output.
[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 -
Hmm, nothing there then.
It pretty much has to be some dynamic rule change.... Hmm -
Despite unticking "Packets blocked due to IP options" in the log-settings, those entries still come up.
-
@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 argumentLooks like 'pf' and 'pfctl' don't speak same language ^^
-
@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: -
@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.
-
@tinfoilmatt said in New log type entry?:
...feels like a mess.
What is the output if you run this command...
-
[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 -
@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 argumentIf 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.
No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
@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.
-
[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...
-
@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.
-
@tinfoilmatt said in New log type entry?:
...feels like a mess.
There are a lot of interfaces but that all looks like expected output.
-
@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....
-
@stephenw10 If by "interfaces" you mean 'four virtualized interfaces, some outrageous number of virtual sub-virtualized interfaces, and a buncha WireGuard sprinkled in'—sure.
-
Ha, well levels of outrage may vary!
-
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.
