Packets go through, logging is set, but no logs of the traffic

silviub

@stephenw10 Yes, I can see the states and packets next to the rule.
The firewall loads with no issues, just did it.

Nothing changed.

stephenw10

Hmm, OK. Check the actual ruleset in /tmp/rules.debug. Do you see your custom rule? Does it have 'log' set?

silviub

@stephenw10
pass in log quick on $WAN reply-to ( vtnet0 a.b.c.d ) inet proto udp from any to 10.151.0.5 port 1194 ridentifier 1702983321 keep state label "USER_RULE: OpenVPN" label "id:1702983321"

Yes, it seems to have the log stanza (pass in log quick).

chpalmer

@silviub said in Packets go through, logging is set, but no logs of the traffic:

but there isn't really any client here

Just a refresher coarse.. client device requests... server listens and grants. rinse and repeat.

Very basic.. Cant have a connection between two computers without that.

Carry on.

silviub

@chpalmer while you're technically right, I was replying to stephenw10, who said

An OpenVPN connection like that could be open for months so it's possible any states you see were created before you enabled logging?

So, in that regard, there wasn't a VPN client that kept the connections open. Please read above.

stephenw10

Is the firewall logging anything? If you create some other rule as a test with logging does it work as expected?

silviub

@stephenw10 Yes, it does. And weirdly enough, some packets in this rule are logged, while others are not. I tried from two different public IPs to nc -u <IP> <port> and one got logged, one didn't, even though in States I see both of them.... What's going on?! :D

P.S. It can't match a different rule - one that is not logging let's say - because ALL my rules are set to log. So no matter what rule it'd match, I'd have to see it in the logs.

When I opened this forum post I tried to reach the machine from a certain public IP. That was on the 17th of October. I can still see that log line. If I open a new connection (different source port, naturally), the traffic is forwarded properly, the traffic reaches the target machine, but I don't see the connection in the logs, even though I see it in the states.

P.S. could it be an issue that the target machine doesn't reply? Since this is UDP, I get no reply from the target....?

stephenw10

Hmm, I mean matching some other unexpected rule is about the only thing I could imagine doing this. It could be something dynamic perhaps.

If you check states created by the traffic using pfctl -vss and grep-ing for something do you see the expected rule number? The same rule number on very state?

silviub

@stephenw10

# 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_TRAFFIC

I don't see a rule number anywhere.

stephenw10

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@mvneta2

You 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 ]

silviub

@stephenw10

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

stephenw10

Just to confirm is this the only rule you are seeing fail to log?

silviub

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

stephenw10

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?

stephenw10

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?