pfSense

fix:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/646

The status logic relies on the settings in the GUI fields to determine how to query the OpenVPN management interface. If you are using custom options for certain aspects of the configuration which conflict with what it shown in the GUI settings, the status code has no way to properly determine which method to use when making a query to the management interface.

You could use the system patches package to back out the other change (or apply a different one) to accommodate your customizations, but I don't think changing our code in a way that would break other valid modes to make this kind of custom setup work is a viable path forward.

If the existing server bridge GUI options are not working for your use case a better fix would be to implement changes that would allow you to make the configuration you need using the GUI. This would be fixed as a side effect. That is a fundamentally different feature request though, not a bug.

I've been able to reproduce it with a configuration that only uses the GUI options and no custom options, attached.

I don't think the GUI needs to interpret custom options, it just needs to realise that <mode>server_tls_user</mode> (in the config.xml settings) means that multiple users can connect and it should report the list of users. That corresponds to "Server mode: Remote Access (SSL/TLS + User Auth)" in the GUI.

(Looking back at #12232, the problematic config in that case had a mode of p2p_tls, which would correctly be interpreted as peer-to-peer. But the change made for that bug sweeps up any tap-mode service including user remote access.)

Feel free to test the following patch and let us know if it resolves your issue:

diff --git a/src/etc/inc/openvpn.inc b/src/etc/inc/openvpn.inc
index 73cf7b4ab7..fce552f5f1 100644
--- a/src/etc/inc/openvpn.inc
+++ b/src/etc/inc/openvpn.inc
@@ -1889,12 +1889,11 @@ function openvpn_get_active_servers($type="multipoint") {
                        list($tn, $sm) = openvpn_gen_tunnel_network($settings['tunnel_network']);

                        if ((($server['mode'] == "p2p_shared_key") ||
-                           (($settings['dev_mode'] == 'tap') && empty($settings['tunnel_network'])) ||
+                           (($settings['dev_mode'] == 'tap') && empty($settings['tunnel_network']) && ($server['mode'] == 'p2p_tls')) ||
                            ($sm >= 30)) &&
                            ($type == "p2p")) {
                                $servers[] = openvpn_get_client_status($server, $socket);
                        } elseif (($server['mode'] != "p2p_shared_key") &&
-                           !(($settings['dev_mode'] == 'tap') && empty($settings['tunnel_network'])) &&
                            ($type == "multipoint") &&
                            ($sm < 30)) {
                                $servers[] = openvpn_get_server_status($server, $socket);

Applied in changeset 5f3aa9464e9b9b8062faa47e7552552ff3841d92.

The patch above resolves my issue -- once applied, the user remote access service displays client connections.

However, I think it regresses #12232 slightly. The patch makes the p2p_tls service from #12232 appear twice, as both an empty Client Connections box and the Peer-to-Peer Instance details. Refer 02-patched-p2p-appears-twice.png.

I get what I think is more correct output if the elseif clause keeps a negative version of the if clause, i.e. applying this instead of the patch above gives the result in 03-alternative-patch.png. The only difference is the extra added line:

--- a/src/etc/inc/openvpn.inc
+++ b/src/etc/inc/openvpn.inc
@@ -1889,12 +1889,12 @@ function openvpn_get_active_servers($type="multipoint") {
             list($tn, $sm) = openvpn_gen_tunnel_network($settings['tunnel_network']);

             if ((($server['mode'] == "p2p_shared_key") ||
-                (($settings['dev_mode'] == 'tap') && empty($settings['tunnel_network'])) ||
+                (($settings['dev_mode'] == 'tap') && empty($settings['tunnel_network']) && ($server['mode'] == 'p2p_tls')) ||
                 ($sm >= 30)) &&
                 ($type == "p2p")) {
                 $servers[] = openvpn_get_client_status($server, $socket);
             } elseif (($server['mode'] != "p2p_shared_key") &&
-                !(($settings['dev_mode'] == 'tap') && empty($settings['tunnel_network'])) &&
+                !(($settings['dev_mode'] == 'tap') && empty($settings['tunnel_network']) && ($server['mode'] == 'p2p_tls')) &&
                 ($type == "multipoint") &&
                 ($sm < 30)) {
                 $servers[] = openvpn_get_server_status($server, $socket);

But strictly referring to the server_tls_user service in this bug #12884, either version of the patch works for me.

Evan Pearce wrote in #note-9:

The patch above resolves my issue -- once applied, the user remote access service displays client connections.

However, I think it regresses #12232 slightly. The patch makes the p2p_tls service from #12232 appear twice, as both an empty Client Connections box and the Peer-to-Peer Instance details. Refer 02-patched-p2p-appears-twice.png.

I get what I think is more correct output if the elseif clause keeps a negative version of the if clause, i.e. applying this instead of the patch above gives the result in 03-alternative-patch.png. The only difference is the extra added line:

https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/665

Merged:
https://github.com/pfsense/pfsense/commit/9be20fdf57fe9c9c17aa16542189854dbf1cbebd

Updating subject for release notes.