OpenVPN client overrides not updating in 23.7.5 #6915

Support-Zylon · 2023-10-05T13:28:12Z

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

OpenVPN client overrides page is not updating /var/etc/openvpn-csc/[0-9]+/ items/files

A clear and concise description of what the bug is, including last known working version (if any).

Tip: to validate your setup was working with the previous version, use opnsense-revert (https://docs.opnsense.org/manual/opnsense_tools.html#opnsense-revert)

To Reproduce

Steps to reproduce the behavior:

When you go to https://opensense/ui/openvpn/client_overwrites
Add a user / common name to have overrides for openvpn client
There will be no entire made in /var/etc/openvpn-csc/[0-9]+/ with that common name or user

Expected behavior

Expected is that a user / common name entry in /var/etc/open-csc/ .. / is made

If you add common name test a file with content of specific overrides will be created

/var/etc/openvpn-csc/1/test
with data like:

ifconfig-push "route 192.168.255.250 192.168.255.249"
push "route 10.0.20.0 255.255.255.0"

A clear and concise description of what you expected to happen.

Describe alternatives you considered
I have added the items manual and that solves the issue for now. But config via gui is not synced to "/var/etc/openvpn-csc/[0-9]+/" dir. This could cause missing updates or mall configuration.

A clear and concise description of any alternative solutions or workaround you considered.

OPNSsense 23.7.5 (amd64 OpenSSL)
Intel(R) Xeon(R) CPU E31230
Network Intel® I210-AT

AdSchellevis · 2023-10-05T13:58:05Z

Best check the OpenVPN logs first, these files are being written on login normally.

core/src/opnsense/scripts/openvpn/user_pass_verify.php

Line 133 in e5e8d00

    
           syslog(LOG_NOTICE, "user '{$username}' authenticated using '{$authName}' {$tmp}:{$cso_filename}");

Support-Zylon · 2023-10-05T14:42:28Z

Users are normally authenticated. And also matched against the cso. But from the gui provisioning the user cso file is not created any more or updated.

So existing user with cso file will match and use that but new users don't match as their specific config is missing.
Manual adding the cso file will match again. That is my current work around to be able to give specific access by openvpn.

The problem is in the provisioning adding and changing custom override that creates the cso_filename. That part is not working anymore.

Regards

Robert

AdSchellevis · 2023-10-05T15:05:27Z

and what's in the log?

Support-Zylon · 2023-10-05T15:09:54Z

In the logs is for the authenticated users with matched cso-filename. But if the user has been changed via the gui. The changes are not commited to the cso-filename. For new users the cso-filename is not created so no match off course and the user will get the default config from openvpn. The problem is with adding or changing options in the gui for thje cso-filename.

The problem is not on the authentication of openvpn but in configuration in the gui which are not saved to /var/etc/openvpn-csc/1/user

AdSchellevis · 2023-10-05T15:18:47Z

This is what I tried to explain earlier. these files are being created when a user logs in (has been for many years on our end)... which is why the logs are very important to debug issues.

Support-Zylon · 2023-10-06T06:49:58Z

Ok i missed that part.

For existiing users with exsisting file and no changes it shows the line "using "authname" CSO ... in the log. For new users it does not. Also for existing "working" users new settings are not added and are now only reporting using "authname"

So something changes when user / openvpn overrides settings are changed. After this no matching is done anymore.

Support-Zylon · 2023-10-06T13:35:39Z

Hi,

While searching in the code github it seems the function in file src/etc/inc/plugins.inc.d/openvpn.inc function openvpn_csc_conf_write($settings, $server, $target_filename = null) is not triggered or executed anymore when changing user/common name overrides. How can I check if this function is called correctly and creates the correct openvpn-csc/id/commonname file ?

Unfortunately I'm not a coder so its a bit of a challenge to follow this code for me.

AdSchellevis · 2023-10-06T13:40:17Z

it all starts with log output.... details matter

Support-Zylon · 2023-10-06T13:50:58Z

What output do you need. I reported the output lines

<29>1 2023-10-06T13:19:18+02:00 openvpn_server1 16861 - [meta sequenceId="18"] TLS: Username/Password authentication deferred for username 'user1' [CN SET]
<37>1 2023-10-06T13:19:18+02:00 openvpn 19838 - [meta sequenceId="23"] user 'user1' authenticated using 'Local Database'
<29>1 2023-10-06T14:00:43+02:00 openvpn_server1 16861 - [meta sequenceId="15"] user2/ TLS: Username/Password authentication deferred for username 'user2' [CN SET]
<37>1 2023-10-06T14:00:43+02:00 openvpn 6430 - [meta sequenceId="17"] user 'user2' authenticated using 'Local Database' CSO [CN]:/var/etc/openvpn-csc/1/user2
<29>1 2023-10-06T14:16:53+02:00 openvpn_server1 16861 - [meta sequenceId="19"] user1/ TLS: Username/Password authentication deferred for username 'user1' [CN SET]
<37>1 2023-10-06T14:16:53+02:00 openvpn 32398 - [meta sequenceId="21"] user 'user1' authenticated using 'Local Database' CSO [CN]:/var/etc/openvpn-csc/1/user1
<29>1 2023-10-06T14:56:04+02:00 openvpn_server1 16861 - [meta sequenceId="15"] user2/ TLS: Username/Password authentication deferred for username 'user2' [CN SET]
<37>1 2023-10-06T14:56:04+02:00 openvpn 92153 - [meta sequenceId="17"] user 'user2' authenticated using 'Local Database' CSO [CN]:/var/etc/openvpn-csc/1/user2
<29>1 2023-10-06T15:08:00+02:00 openvpn_server1 16861 - [meta sequenceId="16"] TLS: Username/Password authentication deferred for username 'user3' [CN SET]
<37>1 2023-10-06T15:08:00+02:00 openvpn 52162 - [meta sequenceId="21"] user 'user3' authenticated using 'Local Database'
<29>1 2023-10-06T15:27:17+02:00 openvpn_server1 16861 - [meta sequenceId="17"] TLS: Username/Password authentication deferred for username 'user4' [CN SET]
<37>1 2023-10-06T15:27:17+02:00 openvpn 19235 - [meta sequenceId="22"] user 'user4' authenticated using 'Local Database'
<29>1 2023-10-06T15:34:11+02:00 openvpn_server1 16861 - [meta sequenceId="17"] TLS: Username/Password authentication deferred for username 'user4' [CN SET]
<37>1 2023-10-06T15:34:11+02:00 openvpn 3608 - [meta sequenceId="20"] user 'user4' authenticated using 'Local Database'
<29>1 2023-10-06T15:38:29+02:00 openvpn_server1 16861 - [meta sequenceId="17"] TLS: Username/Password authentication deferred for username 'user4' [CN SET]
<37>1 2023-10-06T15:38:29+02:00 openvpn 54462 - [meta sequenceId="20"] user 'user4' authenticated using 'Local Database'

only the user2 is reporting CSO match that user was not changed the other users have changed config added or removed "local networks" for them. To provide the service they needed I have manual added / changed the user files for them. As the provisioning (gui vpn -> openvpn -> client overrides) does not update them anymore

AdSchellevis · 2023-10-06T13:59:26Z

Could be a mismatch in common name or a misconfiguration in the cso configuration, as user2 works, it's unlikely a bug.

Support-Zylon · 2023-10-06T14:03:08Z

While digging in to older few days I see same user sometimes with:

Like today for user3

<29>1 2023-10-06T13:01:16+02:00 openvpn_server1 16861 - [meta sequenceId="16"] user3/ TLS: Username/Password authentication deferred for username 'user3' [CN SET]
<37>1 2023-10-06T13:01:16+02:00 openvpn 93644 - [meta sequenceId="18"] user 'user3' authenticated using 'Local Database' CSO [CN]:/var/etc/openvpn-csc/1/user3
<29>1 2023-10-06T15:08:00+02:00 openvpn_server1 16861 - [meta sequenceId="16"] TLS: Username/Password authentication deferred for username 'user3' [CN SET]
<37>1 2023-10-06T15:08:00+02:00 openvpn 52162 - [meta sequenceId="21"] user 'user3' authenticated using 'Local Database'

But the /var/etc/openvpn-csc/1/user3 file is not created correctly. So why is it matched sometimes and then not. Also why does the user file(s) not created or updated? even if match statement is reported.

AdSchellevis · 2023-10-06T14:13:25Z

My community support time is limited, I'll leave this open in case someone else wants to step in. At a first glance I don't expect a bug, but views may change. The user match (resulting in the log entries) is rather straight forward.

Support-Zylon · 2023-10-06T14:27:17Z

And new added users I have not yet seen a match CSO ,... line entry.

Only for pre 23.x OPNsense users are matched when no change has been done to their config. If changes have been done. match will be random and the openvpn-csc/1/user file is not updated with correct "local net" routing.

Support-Zylon · 2023-10-06T14:55:02Z

Just one quick question. When are the csc files created for the openvpn user. When you create a client override entry or when the specific user authenticates with openvpn to the system?

AdSchellevis · 2023-10-06T15:10:04Z

when they authenticate, this is also to make sure you can provision data from radius for example.

Support-Zylon · 2023-10-09T08:05:05Z

Its strange, I see on older users matches using CSO but new users match both only local database without CSO and local database with CSO. It should always match the CSO line I think? Just a quick question may be this is a rights issue on the /var/etc/openvpn-csc/(server)/ directory and files? Where can i find the correct file rights for these files?

Support-Zylon · 2023-10-09T08:46:55Z

I think I have found a possible difference between authentication sessions.

When openvpn server logs: peer info: IV_SSO= some different / variable options TLS: Username / Password authentication deferred for username 'user' [CN SET] And the CSO matching is done.

I'me now search why sometimes IV_SSO= line is missing on some clients and my own commandline openvpn (OpenVPN 2.6.6 amd64-portbld-freebsd13.2 ) and with tunnelblick we see random matching and not matching.

Problem is why is it matching sometimes and more often not.

fichtner · 2023-10-17T06:30:42Z

Related forum post: https://forum.opnsense.org/index.php?topic=36461.0

cs-1 · 2023-11-15T07:38:09Z

I have the same issue in OPNsense 23.7.8_1-amd64, however, in my case, an OpenVPN server has been created from scratch under "Instances [new]", same for the CSO. My log entries show the correct user name but the CSO never seems to match and nothing is created under /var/etc/openvpn-csc/(server)/ .

fichtner · 2023-11-15T07:52:08Z

Logs please :)

AdSchellevis · 2023-11-15T07:53:00Z

I don't seen anything obvious, but logs for a session which didn't work and a config snippet for one cso that should match according to the common name and selected server might help.

cs-1 · 2023-11-15T08:04:17Z

You're both right, I'm terribly sorry. :)

Thanks for your explanation, @AdSchellevis, I now understand that the CSO file would appear during the login process.

I think I might have found the cause for the problem for my use case. Since I use "Instances [new]" to create a server I don't have the "Force CSO Login Matching" option. I do use the "Username as CN" in my "Instances [new]" server configuration because we don't use client certificates (just uid+pw authentication). However, I only get

2023-11-14T13:01:21 | Notice | openvpn | user 'myusername' authenticated using 'AD TOTP: Staff'
-- | -- | -- | --

("myusername" is correctly set to the username used for login.) What I'm missing is something like CSO [USER] in the log message which would be expected if CSO matching would've worked.

Looking at the source code of

core/src/opnsense/scripts/openvpn/user_pass_verify.php

Line 123 in e5e8d00

    
           $common_name = empty($a_server['cso_login_matching']) ? $common_name : $username;

I'm wondering whether $a_server['cso_login_matching'] would ever be set for "Instances [new]" servers? I haven't found any way to do "Force CSO Login Matching" for "Instances [new]" servers.

cs-1 · 2023-11-15T08:07:40Z

I just realised that I'm wrong, $a_server['cso_login_matching'] seems to be set because the correct username is used in the logs. Then the question is, why

core/src/opnsense/scripts/openvpn/user_pass_verify.php

Line 130 in e5e8d00

$cso_filename = openvpn_csc_conf_write($cso, $a_server);

seems to return an empty file.

This is the config snipped of the CSO:

        <Overwrite uuid="XXXXX">
          <enabled>1</enabled>
          <servers>XXXXXXXX</servers>
          <common_name>myusername</common_name>
          <block>0</block>
          <push_reset>0</push_reset>
          <tunnel_network>192.168.1.101/24</tunnel_network>
          <tunnel_networkv6>2001:DB8::101/64</tunnel_networkv6>
          <local_networks/>
          <remote_networks/>
          <route_gateway/>
          <redirect_gateway/>
          <register_dns>0</register_dns>
          <dns_domain/>
          <dns_domain_search/>
          <dns_servers/>
          <ntp_servers/>
          <wins_servers/>
          <description>User overwriting</description>
        </Overwrite>

AdSchellevis · 2023-11-15T09:05:34Z

ok, so the interesting question is, does the number in <servers>XXXXXXXX</servers> match with the instance your trying to use and does it make a difference when no servers (all) are selected? I assume myusername matches the username in this example as your log seems to suggest so.

cs-1 · 2023-11-15T11:43:04Z

The uuids of the server is correctly referenced in the CSO:

    <OpenVPN version="1.0.0">
      <Overwrites>
        <Overwrite uuid="f8573276-b844-431f-8fca-ce37257cd135">
          <enabled>1</enabled>
          <servers>af407f96-469b-4d8a-aad9-8ec6c4b21034</servers>
          <common_name>myusername</common_name>
          ...
        </Overwrite>
      </Overwrites>
      <Instances>
        <Instance uuid="af407f96-469b-4d8a-aad9-8ec6c4b21034">
          <vpnid>1</vpnid>
          <enabled>1</enabled>
          <dev_type>tun</dev_type>
          <verb>3</verb>
          ...

And I can confirm that the username matches as well.

When configuring the CSO, the only other option to select (apart from the configured instance) is "( / )" which was selected by default. Is that synonymous with "all"? Please note that no other "Instances [new]" (except for the one mentioned here) or classic Server instances are configured on the box.

cs-1 · 2023-11-15T11:49:08Z

I just checked, it makes no difference whether I select the server instance or none at all. The CSO doesn't match.

…g for a CSO, might help track #6915

AdSchellevis · 2023-11-15T13:05:31Z

@cs-1 can you try to add 59d599b ? it should log the relevant entries needed to match the cso.

AdSchellevis · 2023-11-15T15:19:30Z

@cs-1 this bdaa47e should do the trick then.

cs-1 · 2023-11-15T15:28:58Z

@AdSchellevis amazing work! Your patch does the trick:

2023-11-15T16:22:56	Notice	openvpn_server1	myusername/2001:db8:4:1::130 PUSH: Received control message: 'PUSH_REQUEST'	
2023-11-15T16:22:52	Notice	openvpn_server1	myusername/2001:db8:4:1::130 Timers: ping 10, ping-restart 120	
2023-11-15T16:22:52	Notice	openvpn_server1	myusername/2001:db8:4:1::130 Data Channel: cipher 'AES-256-GCM', peer-id: 0	
2023-11-15T16:22:52	Notice	openvpn_server1	myusername/2001:db8:4:1::130 SENT CONTROL [myusername]: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DOMAIN XXXXXXX,dhcp-option DNS 192.168.2.5,dhcp-option DNS 192.168.2.6,dhcp-option DNS 192.168.33.186,dhcp-option NTP 192.168.2.30,dhcp-option NTP 192.168.2.26,dhcp-option NTP 192.168.2.6,tun-ipv6,route-gateway 192.168.7.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 2001:db8:7::101/64 2001:db8:7::1,ifconfig 192.168.7.101 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)	
2023-11-15T16:22:52	Notice	openvpn_server1	myusername/2001:db8:4:1::130 MULTI: primary virtual IPv6 for myusername/2001:db8:4:1::130: 2001:db8:7::101	
2023-11-15T16:22:52	Notice	openvpn_server1	myusername/2001:db8:4:1::130 MULTI: Learn: 2001:db8:7::101 -> myusername/2001:db8:4:1::130	
2023-11-15T16:22:52	Notice	openvpn_server1	myusername/2001:db8:4:1::130 MULTI: primary virtual IP for myusername/2001:db8:4:1::130: 192.168.7.101	
2023-11-15T16:22:52	Notice	openvpn_server1	myusername/2001:db8:4:1::130 MULTI: Learn: 192.168.7.101 -> myusername/2001:db8:4:1::130	
2023-11-15T16:22:51	Notice	openvpn_server1	myusername/2001:db8:4:1::130 MULTI_sva: push_ifconfig_ipv6 2001:db8:7::101/64	
2023-11-15T16:22:51	Notice	openvpn_server1	myusername/2001:db8:4:1::130 OPTIONS IMPORT: reading client specific options from: /var/etc/openvpn-csc/1/myusername	
2023-11-15T16:22:51	Notice	openvpn_server1	myusername/2001:db8:4:1::130 MULTI_sva: pool returned IPv4=192.168.7.2, IPv6=2001:db8:7::1000	
2023-11-15T16:22:50	Notice	openvpn	user 'myusername' authenticated using 'AD TOTP: Staff' CSO [USER]:/var/etc/openvpn-csc/1/myusername	
2023-11-15T16:22:50	Notice	openvpn	Locate overwrite for 'myusername' using server 'af407f96-469b-4d8a-aad9-8ec6c4b21034' (vpnid : 1	
2023-11-15T16:22:50	Notice	openvpn_server1	2001:db8:4:1::130 [myusername] Peer Connection Initiated with [AF_INET6]2001:db8:4:1::130:63819 (via 2001:db8:ff00::32:2%vmx0)	
2023-11-15T16:22:50	Notice	openvpn_server1	2001:db8:4:1::130 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384	
2023-11-15T16:22:50	Notice	openvpn_server1	2001:db8:4:1::130 TLS: tls_multi_process: initial untrusted session promoted to semi-trusted	
2023-11-15T16:22:50	Notice	openvpn_server1	2001:db8:4:1::130 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1	
2023-11-15T16:22:50	Notice	openvpn_server1	2001:db8:4:1::130 TLS: Username/Password authentication deferred for username 'myusername' [CN SET]	
2023-11-15T16:22:50	Notice	openvpn_server1	2001:db8:4:1::130 peer info: IV_GUI_VER="net.tunnelblick.tunnelblick_5779.1_3.8.8e__build_5779.1)"	
2023-11-15T16:22:50	Notice	openvpn_server1	2001:db8:4:1::130 peer info: IV_TCPNL=1	
2023-11-15T16:22:50	Notice	openvpn_server1	2001:db8:4:1::130 peer info: IV_COMP_STUBv2=1	
2023-11-15T16:22:50	Notice	openvpn_server1	2001:db8:4:1::130 peer info: IV_COMP_STUB=1	
2023-11-15T16:22:50	Notice	openvpn_server1	2001:db8:4:1::130 peer info: IV_LZO=1	
2023-11-15T16:22:50	Notice	openvpn_server1	2001:db8:4:1::130 peer info: IV_LZ4v2=1	
2023-11-15T16:22:50	Notice	openvpn_server1	2001:db8:4:1::130 peer info: IV_LZ4=1	
2023-11-15T16:22:50	Notice	openvpn_server1	2001:db8:4:1::130 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM	
2023-11-15T16:22:50	Notice	openvpn_server1	2001:db8:4:1::130 peer info: IV_NCP=2	
2023-11-15T16:22:50	Notice	openvpn_server1	2001:db8:4:1::130 peer info: IV_PROTO=6	
2023-11-15T16:22:50	Notice	openvpn_server1	2001:db8:4:1::130 peer info: IV_PLAT=mac	
2023-11-15T16:22:50	Notice	openvpn_server1	2001:db8:4:1::130 peer info: IV_VER=2.5.9

Thank you for your help and the time you invest in the project, it's highly appreciated!

AdSchellevis · 2023-11-15T15:31:47Z

@cs-1 thank you for confirming!

PR: #6915 (cherry picked from commit bdaa47e) (cherry picked from commit 59d599b) (cherry picked from commit 1120925)

cs-1 · 2023-11-16T06:47:45Z

@AdSchellevis it's the least I can do! I appreciate your help, thanks again.

@fichtner if it's not too much trouble do you think this fix could make it into the next minor update of 23.7.8_1-amd64? We're currently in the progress of moving all of our university's VPN infrastructure to OPNsense and it would be amazing if the fix would be available so that no manual patching is necessary.

Thanks again for your help, guys, it's highly appreciated!

cs-1 · 2023-11-16T06:56:25Z

P. S.: Just in case: is it possible to apply 5b3c236 using opnsense-patch 5b3c236?

fichtner · 2023-11-16T07:03:56Z

yep, opnsense-patch works most of the time. If it doesn't it won't apply the patch, but I don't think that's the case here. If you want to have a clean slate for patching revert to the latest core package first:

# opnsense-revert opnsense && opnsense-patch 5b3c236

This gets rid of local modification too to allow a clean patch apply :)

cs-1 · 2023-11-28T11:20:03Z

Quick feedback: I reverted the patch and upgraded to OPNsense 23.7.9-amd64 and your fix works as expected. Thanks again, guys!

Support-Zylon · 2023-11-29T09:49:26Z

Hi I tested this today with:
OPNsense 23.7.9-amd64
FreeBSD 13.2-RELEASE-p5
OpenSSL 1.1.1w

But it still does not work for us. In the logs:

2023-11-29T10:35:53 Notice openvpn_server1 robert/2a01:1XXXX MULTI_sva: pool returned IPv4=192.168.255.6, IPv6=(Not enabled)
2023-11-29T10:35:52 Notice openvpn user 'robert' authenticated using 'Local Database'
2023-11-29T10:35:52 Notice openvpn_server1 2a01:1:XXXX [robert] Peer Connection Initiated with [AF_INET6]2a01:1XXXX (via 2a01:XXXX)
2023-11-29T10:35:52 Notice openvpn_server1 2a01:1XXX TLS: Username/Password authentication deferred for username 'robert' [CN SET]

And in the client specific overrides it should have used 192.168.255.108/30 and add extra route for 10.5.54.0/24

Enter Auth Username:robert
Enter Auth Password:
2023-11-29 10:35:52 TCP/UDP: Preserving recently used remote address: [AF_INET6]2a01XXXX:1194
2023-11-29 10:35:52 setsockopt(IPV6_V6ONLY=0)
2023-11-29 10:35:52 UDPv6 link local (bound): [AF_INET6][undef]:0
2023-11-29 10:35:52 UDPv6 link remote: [AF_INET6]2a01:XXXXX:1194
2023-11-29 10:35:52 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2023-11-29 10:35:52 [HOSTNAME] Peer Connection Initiated with [AF_INET6]2a01:XXXXX:1194
2023-11-29 10:35:53 TUN/TAP device /dev/tun0 opened
2023-11-29 10:35:53 /sbin/ifconfig tun0 192.168.255.6 192.168.255.5 mtu 1500 netmask 255.255.255.255 up
add net 192.168.255.1: gateway 192.168.255.5

It seems this patch did not help for us. Created new user (localdatabase) and created new client override. But this does not help.

Any pointers to get this working again?

AdSchellevis · 2023-11-29T09:58:47Z

reverted the patch already shipped in the product?

fichtner · 2023-11-29T10:00:32Z

I don't see the new log line in the log output. Either what @AdSchellevis said or a plain configuration issue.

Support-Zylon · 2023-11-29T10:05:40Z

It seems i missed to revert patch. Which patch is needed to be reverted? Is it this what needs to be done: # opnsense-revert opnsense && opnsense-patch 5b3c236 ?

fichtner · 2023-11-29T10:06:48Z

Just the following, otherwise you scrub the patch from the 23.7.9 release (it's a feature):

# opnsense-revert opnsense

cs-1 · 2023-11-29T10:19:48Z

I don't see the new log line in the log output. Either what @AdSchellevis said or a plain configuration issue.

Indeed. In the new release I get the following log entries for CSOs (as it's supposed to work):

2023-11-28T08:33:48 | Notice | openvpn | user 'myusername' authenticated using 'AD TOTP: Staff' CSO [USER]:/var/etc/openvpn-csc/1/myusername
-- | -- | -- | --

@Support-Zylon: Have you checked whether your CSO definition includes the server instance you're using?

Support-Zylon · 2023-11-29T10:33:26Z

We have in the openvpn server options: Force CSO Login Matching

Support-Zylon · 2023-11-29T10:47:00Z

Hi I did the opnsense-revert opnsense and tried the openvpn again but I still don't get the the same authentication line

Still just these:

openvpn	user 'robert' authenticated using 'Local Database'
openvpn_server1	2a01:1XXXX  TLS: Username/Password authentication deferred for username 'robert' [CN SET]

Support-Zylon · 2023-11-29T10:53:48Z

I added the patch 5b3c236 but it does not the lines
still just:
2023-11-29T11:51:59 Notice openvpn_server1 2a01:1XXXXX 6 TLS: Username/Password authentication deferred for username 'robert' [CN SET]
2023-11-29T11:51:59 Notice openvpn user 'robert' authenticated using 'Local Database'

fichtner · 2023-11-29T10:55:30Z

Jesus Christ, 23.7.9 includes the patch and if you run opnsense-patch you REMOVE it. This appears to be a configuration issue as said previously if neither with or without the patch you hit the existing log message or overwrite code.

Support-Zylon · 2023-11-29T10:56:25Z

Maybe its because we use local users instead of a remote authentication ?

Support-Zylon · 2023-11-29T10:56:57Z

Also reverted patch off course after failed test

Support-Zylon · 2023-11-29T10:58:49Z

I had if working before we upgraded to 23.7.4 or 5 not sure any more. And we did not change configuration. Only added new user. This new user would not get the client specific override anymore. Old user still matched ad they probably have correct openvpn override files so we did not notice issues before.

Support-Zylon · 2023-12-05T09:36:41Z

I still have user matching and not matching:

2023-12-05T09:31:19 Notice openvpn_server1 user1/X.X.X.112:52104 MULTI_sva: pool returned IPv4=192.168.255.10, IPv6=(Not enabled)
2023-12-05T09:31:18 Notice openvpn user 'user1' authenticated using 'Local Database'
2023-12-05T09:31:18 Notice openvpn_server1 X.X.X.112:52104 [user1] Peer Connection Initiated with [AF_INET6]::ffff:X.X.X.112:52104 (via ::ffff:x.x.x.9%lagg0_vlan1021)
2023-12-05T09:31:18 Notice openvpn_server1 X.X.X.112:52104 TLS: Username/Password authentication deferred for username 'user1' [CN SET]

2023-12-04T16:31:26 Notice openvpn user 'user1' authenticated using 'Local Database' CSO [CN]:/var/etc/openvpn-csc/1/user1
2023-12-04T16:31:26 Notice openvpn Locate overwrite for 'user1' using server '1' (vpnid: 1)
2023-12-04T16:31:26 Notice openvpn_server1 user1/X.X.X.112:53948 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer temporary key: 253 bits X25519
2023-12-04T16:31:26 Notice openvpn_server1 user1/X.X.X.112:53948 TLS: Username/Password authentication deferred for username 'user1' [CN SET]

Also new users don't match using user as common-name.

Is there any one here have a good pointer where to look and why matching sometimes works and sometimes not. This is very unreliable for us now.

fwarxma · 2024-04-29T14:55:32Z

I've manually corrected/edited the files in /var/etc/openvpn-csc until this situation is resolved. That worked for me as an interim solution. My version is OPNsense 23.7.12-amd64

AdSchellevis · 2024-04-29T15:30:10Z

efae7a5

Support-Zylon · 2024-04-30T07:22:13Z

Just a update. It seems with 24.1.4 it works without issues. The active users using this vpn get updated configs when logging in with vpn. So it looks like it is fixed.

@fwarxma I would recommend to update/upgrade to 24.1.x which has the fixes and works for me.

AdSchellevis added the support Community support label Oct 5, 2023

AdSchellevis mentioned this issue Oct 7, 2023

OpenVPN client overrides not updating in 23.7.5 #6914

Closed

AdSchellevis added a commit that referenced this issue Nov 15, 2023

VPN: OpenVPN: Client Specific Overrides - add log entry when searchin…

59d599b

…g for a CSO, might help track #6915

AdSchellevis closed this as completed in bdaa47e Nov 15, 2023

AdSchellevis added bug Production bug and removed support Community support labels Nov 15, 2023

AdSchellevis self-assigned this Nov 15, 2023

fichtner added this to the 24.1 milestone Nov 15, 2023

fichtner pushed a commit that referenced this issue Nov 15, 2023

VPN: OpenVPN - obey username_as_common_name setting

5b3c236

PR: #6915 (cherry picked from commit bdaa47e) (cherry picked from commit 59d599b) (cherry picked from commit 1120925)

OpenVPN client overrides not updating in 23.7.5 #6915

OpenVPN client overrides not updating in 23.7.5 #6915

Comments

Support-Zylon commented Oct 5, 2023

AdSchellevis commented Oct 5, 2023

Support-Zylon commented Oct 5, 2023

AdSchellevis commented Oct 5, 2023

Support-Zylon commented Oct 5, 2023

AdSchellevis commented Oct 5, 2023

Support-Zylon commented Oct 6, 2023

Support-Zylon commented Oct 6, 2023

AdSchellevis commented Oct 6, 2023

Support-Zylon commented Oct 6, 2023

AdSchellevis commented Oct 6, 2023

Support-Zylon commented Oct 6, 2023

AdSchellevis commented Oct 6, 2023

Support-Zylon commented Oct 6, 2023

Support-Zylon commented Oct 6, 2023

AdSchellevis commented Oct 6, 2023

Support-Zylon commented Oct 9, 2023

Support-Zylon commented Oct 9, 2023

fichtner commented Oct 17, 2023

cs-1 commented Nov 15, 2023

fichtner commented Nov 15, 2023

AdSchellevis commented Nov 15, 2023

cs-1 commented Nov 15, 2023 • edited Loading

cs-1 commented Nov 15, 2023 • edited Loading

AdSchellevis commented Nov 15, 2023

cs-1 commented Nov 15, 2023

cs-1 commented Nov 15, 2023

AdSchellevis commented Nov 15, 2023

AdSchellevis commented Nov 15, 2023

cs-1 commented Nov 15, 2023 • edited Loading

AdSchellevis commented Nov 15, 2023

cs-1 commented Nov 16, 2023

cs-1 commented Nov 16, 2023

fichtner commented Nov 16, 2023 • edited Loading

cs-1 commented Nov 28, 2023

Support-Zylon commented Nov 29, 2023

AdSchellevis commented Nov 29, 2023

fichtner commented Nov 29, 2023

Support-Zylon commented Nov 29, 2023

fichtner commented Nov 29, 2023 • edited Loading

cs-1 commented Nov 29, 2023

Support-Zylon commented Nov 29, 2023

Support-Zylon commented Nov 29, 2023

Support-Zylon commented Nov 29, 2023

fichtner commented Nov 29, 2023

Support-Zylon commented Nov 29, 2023

Support-Zylon commented Nov 29, 2023

Support-Zylon commented Nov 29, 2023 • edited Loading

Support-Zylon commented Dec 5, 2023

fwarxma commented Apr 29, 2024

AdSchellevis commented Apr 29, 2024

Support-Zylon commented Apr 30, 2024

cs-1 commented Nov 15, 2023 •

edited

Loading

cs-1 commented Nov 15, 2023 •

edited

Loading

cs-1 commented Nov 15, 2023 •

edited

Loading

fichtner commented Nov 16, 2023 •

edited

Loading

fichtner commented Nov 29, 2023 •

edited

Loading

Support-Zylon commented Nov 29, 2023 •

edited

Loading