New log type entry?
-
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: -
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:
