Messages

The problem has been confirmed by Ad Schellevis.
He confirms that Franco is probably right.
The issue has been tagged as a feature request now.

Hi Toon,

This does indeed look suspicious. Perhaps it's best if you open a ticket on GitHub (https://github.com/opnsense/core/issues) with the relevant details you provided so we can track it more accurately.

Cheers,
Stephan

Will do.

Hi, I'm experiencing the same problem.
I use a Captive Portal on top of Wireguard.
The Captive Portal works with HTTPS and a Let's Encrypt certificate.
In the Captive Portal, the automatic generation of firewall rules is turned off.
All required firewall rules have been manually added conform the documentation.

On the client, Wireguard is configured as a full tunnel, with the kill switch active.

It all works like a charm.
The only problem is the activity time-out not working as advertised.
It times out while data is actively streaming through the tunnel with the client.

When the client is NOT in session, the output of the requested pfctl command is:
# pfctl -vs ether -a captiveportal_zone_0
No ALTQ support in kernel
ALTQ related functions disabled

When the client is IN session, the output is:
# pfctl -vs ether -a captiveportal_zone_0
No ALTQ support in kernel
ALTQ related functions disabled
ether pass in quick proto 0x0800 l3 from 192.168.100.2 to any label "192.168.100.2-in"
  [ Evaluations: 0         Packets: 0         Bytes: 0         ]
ether pass out quick proto 0x0800 l3 from any to 192.168.100.2 label "192.168.100.2-out"
  [ Evaluations: 0         Packets: 0         Bytes: 0         ]

With the client in session and playing a YT video, the Interface counters for In4/Pass and Out4Pass increase, while the Block counter remain constant (do not increase):
root@opnsense:/var/log # pfctl -s Interfaces -i wg0 -vv
No ALTQ support in kernel
ALTQ related functions disabled
wg0
        Cleared:     Sat Aug  9 21:13:55 2025
        References:  26               
        In4/Pass:    [ Packets: 340608             Bytes: 40581595           ]
        In4/Block:   [ Packets: 13235              Bytes: 1607356            ]
        Out4/Pass:   [ Packets: 1921721            Bytes: 2551070890         ]
        Out4/Block:  [ Packets: 0                  Bytes: 0                  ]
        In6/Pass:    [ Packets: 0                  Bytes: 0                  ]
        In6/Block:   [ Packets: 0                  Bytes: 0                  ]
        Out6/Pass:   [ Packets: 0                  Bytes: 0                  ]
        Out6/Block:  [ Packets: 0                  Bytes: 0                  ]

In the Web GUI I can request the value of the alias __captive_portal_zone_0.
With the client NOT in session, it is empty.
With the client IN session it contains the Wireguard IP address of the client (192.168.100.2).

Is this problem now confirmed and worked on?
If not, would you like me to register an issue for Development?
Regards,
Toon,
Houten,
The Netherlands.