Packets go through, logging is set, but no logs of the traffic
-
# pfctl -vss | grep x.y.z.xx all udp 10.151.0.5:1194 (a.b.c.d:1194) <- x.y.z.xx:56223 NO_TRAFFIC:SINGLE vtnet2.305 udp x.y.z.xx:56223 -> 10.151.0.5:1194 SINGLE:NO_TRAFFICI don't see a rule number anywhere.
-
Ah sorry you'll need to show the following two lines so something like:
[25.11-BETA][root@fw1.stevew.lan]/root: pfctl -vvss | grep -A 2 9.9.9.9 mvneta0 icmp 9.9.9.9:8 <- 172.21.16.8:1 0:0 age 00:00:11, expires in 00:00:09, 11:11 pkts, 924:924 bytes, anchor 0, rule 147 id: 8c2ef86800000000 creatorid: 92ac4dc8 mvneta2 icmp 192.168.1.5:18952 (172.21.16.8:1) -> 9.9.9.9:8 0:0 age 00:00:11, expires in 00:00:09, 11:11 pkts, 924:924 bytes, anchor 3, rule 118, allow-opts id: 8d2ef86800000000 creatorid: 92ac4dc8 route-to: 192.168.1.1@mvneta2You can then show those rules with:
[25.11-BETA][root@fw1.stevew.lan]/root: pfctl -vvsr | grep -A 4 @147 @147 pass in quick on mvneta0 inet from <LAN__NETWORK:3> to any flags S/SA keep state (if-bound) label "id=0100000101" label "tags=user_rule" label "descr=Default allow LAN to any rule" ridentifier 100000101 [ Evaluations: 49494 Packets: 5811923 Bytes: 3914848338 States: 347 ] [ Source Nodes: 0 Limit: 0 NAT/RDR: 0 Route: 0 ] [ Inserted: uid 0 pid 0 State Creations: 48158 ] [ Last Active Time: Tue Oct 21 01:15:44 2025 ] [25.11-BETA][root@fw1.stevew.lan]/root: pfctl -vvsr | grep -A 4 @118 @118 pass out route-to (mvneta2 192.168.1.1) inet from 192.168.1.5 to ! 192.168.1.0/24 flags S/SA keep state (if-bound) allow-opts label "descr=let out anything from firewall host itself" ridentifier 1000012111 [ Evaluations: 49788 Packets: 4976110 Bytes: 3430787939 States: 265 ] [ Source Nodes: 0 Limit: 0 NAT/RDR: 0 Route: 0 ] [ Inserted: uid 0 pid 0 State Creations: 27846 ] [ Last Active Time: Tue Oct 21 01:16:02 2025 ] -
# pfctl -vvss | grep -A 2 <incoming public IP address> all udp 10.151.0.5:1194 (<Public port forwarding IP Address>:1194) <- <incoming public IP address>:22479 NO_TRAFFIC:SINGLE age 00:00:38, expires in 00:00:14, 17:0 pkts, 523:0 bytes, rule 161 id: 0aed36af00000000 creatorid: b6757fa1 reply-to: x.x.x.x@vtnet0 -- vtnet2.305 udp <incoming public IP address>:22479 -> 10.151.0.5:1194 SINGLE:NO_TRAFFIC age 00:00:38, expires in 00:00:14, 17:0 pkts, 523:0 bytes, rule 86, allow-opts id: 0bed36af00000000 creatorid: b6757fa1 # pfctl -vvsr | grep -A 4 @161 @161 pass in log quick on vtnet0 reply-to (vtnet0 <gateway IP>) inet proto udp from any to 10.151.0.5 port = openvpn keep state (if-bound) label "USER_RULE: OpenVPN" label "id:1702983321" ridentifier 1702983321 [ Evaluations: 500038 Packets: 121423 Bytes: 61146938 States: 0 ] [ Inserted: uid 0 pid 0 State Creations: 5 ] [ Last Active Time: Tue Oct 21 05:22:17 2025 ]So it seems to match the correct rule
While the logs only show an old connection from October 17th.
P.S. if you want, we can have a Zoom / Teams / whatever meeting where you can check stuff out. Still, from my point of view, it doesn't seem to be a configuration issue.
P.S. I appreciate the time you're putting into this.
-
Just to confirm is this the only rule you are seeing fail to log?
-
@stephenw10
unfortunately there's no way to know that. It's the only one I encountered so far, but that doesn't mean there are not others with the same behavior, that I did not discover. -
You're testing this by sending UDP packets to the port right? Does it also fail to log if you actually connect a VPN client to it?
-
Hmm, with a port-forward like this the default would be for the system to auto-create a linked pass rule based on the forward and it would be labelled as such. This looks like a custom rule you have added separately.
What does you port forward rule look like? Is it possible it's set to pass?
-
@stephenw10 Yes, it does fail when an actual OpenVPN client sends traffic since that's how this issue was discovered initially. Clients were connecting to this - or trying to connect, we would see the traffic in the VM but not in PFSense logs.
This rule was auto-created but since the description of the rule was empty, it was edited out so when it's logged, we have an idea of what's logged. The rule itself was auto-created, it was just edited afterwards.
The forwarding policy:
Disabled: unticket No RDR: unticket Interface: WAN Address Family: IPv4 Protocol: UDP Destination: Public IP address (alias) on WAN interface Destination port range: OpenVPN Redirect Target IP: 10.151.0.5 Redirect Target Port: OpenVPN Description: OpenVPN No XMLRPC Sync: not ticket NAT Reflection: Pure NAT Filter rule asociation: <name of rule associated to this NAT rule>. If I click on "View the filter rule" I get redirected to the rule that doesn't log.As I said, if you want to take a look, we can have a Zoom / Teams session as it might be easier for you to check it out (not really comfortable to share public IPs and stuff here :D )
-
@stephenw10
coming back with new info: it seems this is NOT the only rule that's affected. Below, I've specifically set a rule on the correct interface (since I'm seeing states next to that rule) to log ANY traffic from 10.41.199.200 (test host) to 10.41.14.99 (another test host). They're connected via an IPSec VTI tunnel, but I don't expect that to change anything. Below, logs from the PFSense and the device on the other end:
The fact that the traffic is stopped by the 2nd firewall is normal, as I haven't added the rule there yet, but the traffic reaches the 2nd firewall, while it's not logged in the PFSense.
The PFSense rule:
-
Hmm, so that rule is on the internal interface those pings are coming in on? They then leave over the VTI tunnel and are blocked on the remote end?
Is it possible your firewall logs are turning over so fast they are being replaced? Seems unlikely but...
-
@stephenw10 Yes, that's the scenario. Pings are coming in on a local / internal interface and leave via the IPSec VTI interface (same for tunnel mode though, so the IPSec interface mode is not influencing it), and are blocked by the other firewall. So the traffic goes through the PFSense, 100%.
As for the firewall logs turning over so fast.... It's not a really busy box. I mean yeah, there's traffic via this PFSense but it's not a ton of it, so ..... Anyways, I should see SOMETHING, as the ping was running continuously. So at least 1 packet should have been there when refreshing (multiple times)
I've setup a syslog server and will test more today, see if the logs are in there.
-
I've setup the remote syslog server, I'm not getting those logs in the syslog server either. So it's not just a problem with showing the logs in the UI.
-
Hmm, bizarre! And to be clear this is still only happening on those two rules you have found so far? You can still add other new rules and they log as expected?
-
@stephenw10 Well, no. The rule about the VTI was just added. So a new rule had the same issue. I can just assume this is a global issue, on all / most of the rules, but since there's literarily hundreds of rules, it's quite hard to test that.
-
The Filer package can achieve a lot of that. -
@stephenw10 I'm sorry, I didn't get that?
-
Gah! sorry somehow managed to reply to the wrong thread.
