search

OpenVPN / openvpn

OpenVPN is an open source VPN daemon
http://openvpn.net
Other
10.64k stars 2.96k forks source link

client doesn't sent auth-token if auth-user-pass is not defined #296

Open jkroepke opened 1 year ago

jkroepke commented 1 year ago

IMPORTANT NOTE Bugs about OpenVPN Access Server, OpenVPN Connect or any other product by OpenVPN Inc. should be directly reported to OpenVPN Inc. at https://support.openvpn.net

Describe the bug I have a OpenVPN server that uses client certificates and MFA through Web Browser.

Our policies allows to cache the MFA for 24h. If a OpenVPN client reconnects to the server with an valid auth-token, the MFA can skipped.

We are using deferred authentication in combination with OPENURL to ask for Username/Password. Thats why auth-user-pass-optional is configured and the client doesn't have a auth-user-pass directive.

Our POC, it works since #261 fine. But re-authentication happens each 120 seconds. If auth-user-pass is defined on client, the auth-token based re-authentication works fine.

To Reproduce

reneg-sec 120
script-security 3
# auth-user-pass-verify.sh is a script that initiate the deferred authentication method
auth-user-pass-verify "auth-user-pass-verify.sh" via-file
auth-user-pass-optional
auth-gen-token

Expected behavior On TLS, the client should sent a auth-token and the server should bypass the auth through auth-user-pass-verify. (same behavior as auth-user-pass is defined on client)

Version information (please complete the following information): Server

Client

Additional context

Server Logs

Details ``` tests-openvpn-1 | 2023-03-23 20:47:34 Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers. tests-openvpn-1 | 2023-03-23 20:47:34 Note: Kernel support for ovpn-dco missing, disabling data channel offload. tests-openvpn-1 | 2023-03-23 20:47:34 OpenVPN 2.6.1 [git:release/2.6/e950ca1b9fca58e9] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] [DCO] built on Mar 23 2023 tests-openvpn-1 | 2023-03-23 20:47:34 library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10 tests-openvpn-1 | 2023-03-23 20:47:34 DCO version: N/A tests-openvpn-1 | 2023-03-23 20:47:34 net_route_v4_best_gw query: dst 0.0.0.0 tests-openvpn-1 | 2023-03-23 20:47:34 net_route_v4_best_gw result: via 172.19.0.1 dev eth0 tests-openvpn-1 | 2023-03-23 20:47:34 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts tests-openvpn-1 | 2023-03-23 20:47:34 Using random OpenVPN auth-token server key. tests-openvpn-1 | 2023-03-23 20:47:34 TUN/TAP device tun0 opened tests-openvpn-1 | 2023-03-23 20:47:34 net_iface_mtu_set: mtu 1500 for tun0 tests-openvpn-1 | 2023-03-23 20:47:34 net_iface_up: set tun0 up tests-openvpn-1 | 2023-03-23 20:47:34 net_addr_v4_add: 100.64.0.1/24 dev tun0 tests-openvpn-1 | 2023-03-23 20:47:34 Could not determine IPv4/IPv6 protocol. Using AF_INET tests-openvpn-1 | 2023-03-23 20:47:34 Socket Buffers: R=[212992->212992] S=[212992->212992] tests-openvpn-1 | 2023-03-23 20:47:34 UDPv4 link local (bound): [AF_INET][undef]:1194 tests-openvpn-1 | 2023-03-23 20:47:34 UDPv4 link remote: [AF_UNSPEC] tests-openvpn-1 | 2023-03-23 20:47:34 UID set to nobody tests-openvpn-1 | 2023-03-23 20:47:34 GID set to nogroup tests-openvpn-1 | 2023-03-23 20:47:34 Capabilities retained: CAP_NET_ADMIN tests-openvpn-1 | 2023-03-23 20:47:34 MULTI: multi_init called, r=256 v=256 tests-openvpn-1 | 2023-03-23 20:47:34 IFCONFIG POOL IPv4: base=100.64.0.2 size=253 tests-openvpn-1 | 2023-03-23 20:47:34 Initialization Sequence Completed tests-openvpn-1 | 2023-03-23 20:47:35 172.19.0.1:33897 VERIFY OK: depth=1, CN=Easy-RSA CA tests-openvpn-1 | 2023-03-23 20:47:35 172.19.0.1:33897 VERIFY OK: depth=0, CN=user@example.com tests-openvpn-1 | 2023-03-23 20:47:35 172.19.0.1:33897 peer info: IV_VER=2.6.1 tests-openvpn-1 | 2023-03-23 20:47:35 172.19.0.1:33897 peer info: IV_PLAT=win tests-openvpn-1 | 2023-03-23 20:47:35 172.19.0.1:33897 peer info: IV_TCPNL=1 tests-openvpn-1 | 2023-03-23 20:47:35 172.19.0.1:33897 peer info: IV_MTU=1600 tests-openvpn-1 | 2023-03-23 20:47:35 172.19.0.1:33897 peer info: IV_NCP=2 tests-openvpn-1 | 2023-03-23 20:47:35 172.19.0.1:33897 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM tests-openvpn-1 | 2023-03-23 20:47:35 172.19.0.1:33897 peer info: IV_PROTO=990 tests-openvpn-1 | 2023-03-23 20:47:35 172.19.0.1:33897 peer info: IV_LZO_STUB=1 tests-openvpn-1 | 2023-03-23 20:47:35 172.19.0.1:33897 peer info: IV_COMP_STUB=1 tests-openvpn-1 | 2023-03-23 20:47:35 172.19.0.1:33897 peer info: IV_COMP_STUBv2=1 tests-openvpn-1 | 2023-03-23 20:47:35 172.19.0.1:33897 peer info: IV_GUI_VER=OpenVPN_GUI_11 tests-openvpn-1 | 2023-03-23 20:47:35 172.19.0.1:33897 peer info: IV_SSO=openurl,webauth,crtext tests-openvpn-1 | 2023-03-23 20:47:36 172.19.0.1:33897 SENT CONTROL [user@example.com]: 'AUTH_PENDING,timeout 60' (status=1) tests-openvpn-1 | 2023-03-23 20:47:36 172.19.0.1:33897 SENT CONTROL [user@example.com]: 'INFO_PRE,OPEN_URL:https://jkroepke.github.io/openvpn-auth-azure-ad/?code=CUAJGVDXW' (status=1) tests-openvpn-1 | 2023-03-23 20:47:36 172.19.0.1:33897 TLS: Username/Password authentication deferred for username '' tests-openvpn-1 | 2023-03-23 20:47:36 172.19.0.1:33897 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1 tests-openvpn-1 | 2023-03-23 20:47:36 172.19.0.1:33897 TLS: tls_multi_process: initial untrusted session promoted to semi-trusted tests-openvpn-1 | 2023-03-23 20:47:36 172.19.0.1:33897 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 256 bit ED25519, signature: ED25519 tests-openvpn-1 | 2023-03-23 20:47:36 172.19.0.1:33897 [user@example.com] Peer Connection Initiated with [AF_INET]172.19.0.1:33897 tests-openvpn-1 | 2023-03-23 20:47:37 172.19.0.1:33897 PUSH: Received control message: 'PUSH_REQUEST' tests-openvpn-1 | 2023-03-23 20:47:42 172.19.0.1:33897 PUSH: Received control message: 'PUSH_REQUEST' tests-openvpn-1 | 2023-03-23 20:47:47 172.19.0.1:33897 PUSH: Received control message: 'PUSH_REQUEST' tests-openvpn-1 | 2023-03-23 20:47:53 172.19.0.1:33897 PUSH: Received control message: 'PUSH_REQUEST' tests-openvpn-1 | 2023-03-23 20:47:53 user@example.com/172.19.0.1:33897 MULTI_sva: pool returned IPv4=100.64.0.2, IPv6=(Not enabled) tests-openvpn-1 | 2023-03-23 20:47:53 user@example.com/172.19.0.1:33897 MULTI: Learn: 100.64.0.2 -> user@example.com/172.19.0.1:33897 tests-openvpn-1 | 2023-03-23 20:47:53 user@example.com/172.19.0.1:33897 MULTI: primary virtual IP for user@example.com/172.19.0.1:33897: 100.64.0.2 tests-openvpn-1 | 2023-03-23 20:47:53 user@example.com/172.19.0.1:33897 SENT CONTROL [user@example.com]: 'PUSH_REPLY,route-gateway 100.64.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 100.64.0.2 255.255.255.0,peer-id 0,auth-tokenSESS_ID,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500' (status=1) tests-openvpn-1 | 2023-03-23 20:47:54 user@example.com/172.19.0.1:33897 Data Channel: cipher 'AES-256-GCM', peer-id: 0 tests-openvpn-1 | 2023-03-23 20:47:54 user@example.com/172.19.0.1:33897 Timers: ping 10, ping-restart 120 tests-openvpn-1 | 2023-03-23 20:47:54 user@example.com/172.19.0.1:33897 Protocol options: explicit-exit-notify 1, protocol-flags cc-exit tls-ekm dyn-tls-crypt tests-openvpn-1 | 2023-03-23 20:49:29 user@example.com/172.19.0.1:33897 TLS: soft reset sec=113/113 bytes=41901/-1 pkts=311/0 tests-openvpn-1 | 2023-03-23 20:49:29 user@example.com/172.19.0.1:33897 VERIFY OK: depth=1, CN=Easy-RSA CA tests-openvpn-1 | 2023-03-23 20:49:29 user@example.com/172.19.0.1:33897 VERIFY OK: depth=0, CN=user@example.com tests-openvpn-1 | 2023-03-23 20:49:29 user@example.com/172.19.0.1:33897 peer info: IV_VER=2.6.1 tests-openvpn-1 | 2023-03-23 20:49:29 user@example.com/172.19.0.1:33897 peer info: IV_PLAT=win tests-openvpn-1 | 2023-03-23 20:49:29 user@example.com/172.19.0.1:33897 peer info: IV_TCPNL=1 tests-openvpn-1 | 2023-03-23 20:49:29 user@example.com/172.19.0.1:33897 peer info: IV_MTU=1600 tests-openvpn-1 | 2023-03-23 20:49:29 user@example.com/172.19.0.1:33897 peer info: IV_NCP=2 tests-openvpn-1 | 2023-03-23 20:49:29 user@example.com/172.19.0.1:33897 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM tests-openvpn-1 | 2023-03-23 20:49:29 user@example.com/172.19.0.1:33897 peer info: IV_PROTO=990 tests-openvpn-1 | 2023-03-23 20:49:29 user@example.com/172.19.0.1:33897 peer info: IV_LZO_STUB=1 tests-openvpn-1 | 2023-03-23 20:49:29 user@example.com/172.19.0.1:33897 peer info: IV_COMP_STUB=1 tests-openvpn-1 | 2023-03-23 20:49:29 user@example.com/172.19.0.1:33897 peer info: IV_COMP_STUBv2=1 tests-openvpn-1 | 2023-03-23 20:49:29 user@example.com/172.19.0.1:33897 peer info: IV_GUI_VER=OpenVPN_GUI_11 tests-openvpn-1 | 2023-03-23 20:49:29 user@example.com/172.19.0.1:33897 peer info: IV_SSO=openurl,webauth,crtext tests-openvpn-1 | 2023-03-23 20:49:30 user@example.com/172.19.0.1:33897 SENT CONTROL [user@example.com]: 'AUTH_PENDING,timeout 60' (status=1) tests-openvpn-1 | 2023-03-23 20:49:30 user@example.com/172.19.0.1:33897 SENT CONTROL [user@example.com]: 'INFO_PRE,OPEN_URL:https://jkroepke.github.io/openvpn-auth-azure-ad/?code=CYP6RVF5E' (status=1) tests-openvpn-1 | 2023-03-23 20:49:30 user@example.com/172.19.0.1:33897 TLS: Username/Password authentication deferred for username '' tests-openvpn-1 | 2023-03-23 20:49:30 user@example.com/172.19.0.1:33897 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 256 bit ED25519, signature: ED25519 ```
selvanair commented 1 year ago

auth-token is a replacement for password and the client treats it as such. If there is no auth-user-pass in the client config, there is no password to replace and the client doesn't send the token. I may be wrong, but it looks hard to decouple the two in the current design.

That said, when there is no username/password, auth-gen-token is not the right approach for handing REAUTH. Instead your server-side script/management that prompts using OPEN_URL could keep track of past authentications, and allow REAUTH without further prompts until some expiry time is reached. After all its your authentication framework that is initiating the prompt. Be sure to always prompt for initial sessions even if the client had authenticated in the immediate past. The management interface on server side is notified whether its a REAUTH or not, I'm not sure whether scripts and plugins get that info -- there have been many recent changes on that front and I haven't kept track.

BTW, I suppose the 120 sec reneg is for testing -- its too frequent in production use.

jkroepke commented 1 year ago

The issue here is that username/password should ne not entered at OpenVPN level. The script is not able to verify or validate the credentials. The script sends a auth link back to the client and pulling the IDP until the user has logged in.

I thought, I could use the auth-token concept for something like an native session token, resulting in less implementation work.

Handling REAUTH could ne also problematic here. To handle the REAUTH mechanism, I had to store the users refresh_token somewhere. Since the script is not a long running process, I had to store them on disk which might be a security flaw.

BTW, I suppose the 120 sec reneg is for testing -- its too frequent in production use.

Yes.

selvanair commented 1 year ago

Handling REAUTH could ne also problematic here. To handle the REAUTH mechanism, I had to store the users refresh_token somewhere. Since the script is not a long running process, I had to store them on disk which might be a security flaw.

Not sure I understand. In the end its the script that tells openvpn server process that auth succeeded. It can bypass all authentication if its a re-auth request and no "refresh token" is required for that. OpenVPN process keeps track of it and will tell you whether its a re-auth for a previously authenticated session or not. Again. I am not sure this info (whether its re-auth or not) is passed to scripts or not -- the management interface at server-side does get this.

If you also want to emulate "auth-token expiry", you will have to cache some state info (say, CID and timestamp), but nothing sensitive needs to be saved to disk.

A quick hack would be to add an inlined, bogus, username-password in the client config and ignore it in your authentication script.

jkroepke commented 1 year ago

After reading the man page, it seems like auth-token-user [1, 2] covers my use-case. I will test this.

you will have to cache some state info (say, CID and timestamp) This feels not safe enough for me. If the OpenVPN server gets restarted, CIDs are reset.

I will look deeper into the auth-token solution for now.

selvanair commented 1 year ago

This feels not safe enough for me. If the OpenVPN server gets restarted, CIDs are reset.

You wont get a re-auth after restarting the server, but will get an initial auth.

selvanair commented 1 year ago

I understand checking for re-auth doesn't feel as secure as having the client send back a token.

As for auth-token-user, right, I had forgotten about it. But it may not be functional as it stands: we had an issue of the server locking the empty username at first authentication. @schwabe should have more insight into this.

jkroepke commented 1 year ago

But it may not be functional as it stands: we had an issue of the server locking the empty username at first authentication.

true. Here is my config to test this

reneg-sec 120
script-security 3
auth-user-pass-verify "/bin/true" via-env
auth-user-pass-optional
auth-gen-token
push "auth-token-user YXV0aC10b2tlbg=="

The auth work fine 

tests-openvpn-1  | 2023-03-25 19:18:46 172.19.0.1:51775 TLS: Username/Password authentication succeeded for username ''

while reauth with auth-token doesnt work fine:

tests-openvpn-1  | 2023-03-25 19:20:44 user@example.com/172.19.0.1:51775 TLS: Username/auth-token authentication failed for username ''

I may ask, if this is intentional?

The man pages says about auth-token-user: It also allows to use --auth-token in setups that normally do not use username and password.. This is the case here, but it seems like it would not work here.

jkroepke commented 1 year ago

I am not sure this info (whether its re-auth or not) is passed to scripts or not

I also looked through the available environment variables.

The auth-user-pass-verify doesn't get the info, if its AUTH or REAUTH. There is an env variable session_state which is always Initial.

selvanair commented 1 year ago

The auth-user-pass-verify doesn't get the info, if its AUTH or REAUTH. There is an env variable session_state which is always Initial.

That's unfortunate. management interface gets ">CLIENT: CONNECT", ">CLIENT: REAUTH" etc.

selvanair commented 1 year ago

I may ask, if this is intentional? The man pages says about auth-token-user: It also allows to use --auth-token in setups that normally do not use username and password.. This is the case here, but it seems like it would not work here.

AFAICT, this is a known bug yet to be fixed.

jkroepke commented 1 year ago

Should I create a new issue? This issue seems to solved by using auth-token-user.

I can find an existing issue for the empty username issue.

cron2 commented 1 year ago

Hi,

On Sun, Mar 26, 2023 at 08:27:08AM -0700, Jan-Otto Kröpke wrote:

I can find an existing issue for the empty username issue.

I've ran into it when testing auth-token-user handling on the client, and sent a patch

https://patchwork.openvpn.net/project/openvpn2/patch/20221010071229.7935-1-gert@greenie.muc.de/

... which @schwabe did not like (see discussion below the patch), but since nobody else seemed to be affected (... yet) this didn't progress.

So we need to revisit this.

gert

(edited, because github mangles URLs that look like a mail address)

jkroepke commented 1 year ago

Hi @cron2 ,

just to confirm, I post my server logs (verb 3) here.

auth-token is denied without any logged reason. I not seen any error messages like TLS Auth Error

tests-openvpn-1  | 2023-03-27 18:10:06 Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
tests-openvpn-1  | 2023-03-27 18:10:06 Note: Kernel support for ovpn-dco missing, disabling data channel offload.
tests-openvpn-1  | 2023-03-27 18:10:06 OpenVPN 2.6.2 [git:release/2.6/3577442530eb7830] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] [DCO] built on Mar 26 2023
tests-openvpn-1  | 2023-03-27 18:10:06 library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
tests-openvpn-1  | 2023-03-27 18:10:06 DCO version: N/A
tests-openvpn-1  | 2023-03-27 18:10:06 net_route_v4_best_gw query: dst 0.0.0.0
tests-openvpn-1  | 2023-03-27 18:10:06 net_route_v4_best_gw result: via 172.19.0.1 dev eth0
tests-openvpn-1  | 2023-03-27 18:10:06 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
tests-openvpn-1  | 2023-03-27 18:10:06 Using random OpenVPN auth-token server key.
tests-openvpn-1  | 2023-03-27 18:10:06 TUN/TAP device tun0 opened
tests-openvpn-1  | 2023-03-27 18:10:06 net_iface_mtu_set: mtu 1500 for tun0
tests-openvpn-1  | 2023-03-27 18:10:06 net_iface_up: set tun0 up
tests-openvpn-1  | 2023-03-27 18:10:06 net_addr_v4_add: 100.64.0.1/24 dev tun0
tests-openvpn-1  | 2023-03-27 18:10:06 Could not determine IPv4/IPv6 protocol. Using AF_INET
tests-openvpn-1  | 2023-03-27 18:10:06 Socket Buffers: R=[212992->212992] S=[212992->212992]
tests-openvpn-1  | 2023-03-27 18:10:06 UDPv4 link local (bound): [AF_INET][undef]:1194
tests-openvpn-1  | 2023-03-27 18:10:06 UDPv4 link remote: [AF_UNSPEC]
tests-openvpn-1  | 2023-03-27 18:10:06 UID set to nobody
tests-openvpn-1  | 2023-03-27 18:10:06 GID set to nogroup
tests-openvpn-1  | 2023-03-27 18:10:06 Capabilities retained: CAP_NET_ADMIN
tests-openvpn-1  | 2023-03-27 18:10:06 MULTI: multi_init called, r=256 v=256
tests-openvpn-1  | 2023-03-27 18:10:06 IFCONFIG POOL IPv4: base=100.64.0.2 size=253
tests-openvpn-1  | 2023-03-27 18:10:06 Initialization Sequence Completed
tests-openvpn-1  | 2023-03-27 18:10:13 172.19.0.1:41281 VERIFY OK: depth=1, CN=Easy-RSA CA
tests-openvpn-1  | 2023-03-27 18:10:13 172.19.0.1:41281 VERIFY OK: depth=0, CN=user@example.com
tests-openvpn-1  | 2023-03-27 18:10:13 172.19.0.1:41281 peer info: IV_VER=2.6.0
tests-openvpn-1  | 2023-03-27 18:10:13 172.19.0.1:41281 peer info: IV_PLAT=mac
tests-openvpn-1  | 2023-03-27 18:10:13 172.19.0.1:41281 peer info: IV_TCPNL=1
tests-openvpn-1  | 2023-03-27 18:10:13 172.19.0.1:41281 peer info: IV_MTU=1600
tests-openvpn-1  | 2023-03-27 18:10:13 172.19.0.1:41281 peer info: IV_NCP=2
tests-openvpn-1  | 2023-03-27 18:10:13 172.19.0.1:41281 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
tests-openvpn-1  | 2023-03-27 18:10:13 172.19.0.1:41281 peer info: IV_PROTO=478
tests-openvpn-1  | 2023-03-27 18:10:13 172.19.0.1:41281 peer info: IV_LZO_STUB=1
tests-openvpn-1  | 2023-03-27 18:10:13 172.19.0.1:41281 peer info: IV_COMP_STUB=1
tests-openvpn-1  | 2023-03-27 18:10:13 172.19.0.1:41281 peer info: IV_COMP_STUBv2=1
tests-openvpn-1  | 2023-03-27 18:10:13 172.19.0.1:41281 peer info: IV_GUI_VER="net.tunnelblick.tunnelblick_5820_4.0.0beta02__build_5820)"
tests-openvpn-1  | 2023-03-27 18:10:13 172.19.0.1:41281 TLS: Username/Password authentication succeeded for username '' 
tests-openvpn-1  | 2023-03-27 18:10:13 172.19.0.1:41281 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
tests-openvpn-1  | 2023-03-27 18:10:13 172.19.0.1:41281 TLS: tls_multi_process: initial untrusted session promoted to trusted
tests-openvpn-1  | 2023-03-27 18:10:13 172.19.0.1:41281 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 256 bit ED25519, signature: ED25519
tests-openvpn-1  | 2023-03-27 18:10:13 172.19.0.1:41281 [user@example.com] Peer Connection Initiated with [AF_INET]172.19.0.1:41281
tests-openvpn-1  | 2023-03-27 18:10:13 user@example.com/172.19.0.1:41281 MULTI_sva: pool returned IPv4=100.64.0.2, IPv6=(Not enabled)
tests-openvpn-1  | 2023-03-27 18:10:13 user@example.com/172.19.0.1:41281 MULTI: Learn: 100.64.0.2 -> user@example.com/172.19.0.1:41281
tests-openvpn-1  | 2023-03-27 18:10:13 user@example.com/172.19.0.1:41281 MULTI: primary virtual IP for user@example.com/172.19.0.1:41281: 100.64.0.2
tests-openvpn-1  | 2023-03-27 18:10:13 user@example.com/172.19.0.1:41281 SENT CONTROL [user@example.com]: 'PUSH_REPLY,auth-token-user YXV0aC10b2tlbg==,route-gateway 100.64.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 100.64.0.2 255.255.255.0,peer-id 0,auth-tokenSESS_ID,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm,tun-mtu 1500' (status=1)
tests-openvpn-1  | 2023-03-27 18:10:14 user@example.com/172.19.0.1:41281 Data Channel: cipher 'AES-256-GCM', peer-id: 0
tests-openvpn-1  | 2023-03-27 18:10:14 user@example.com/172.19.0.1:41281 Timers: ping 10, ping-restart 120
tests-openvpn-1  | 2023-03-27 18:10:14 user@example.com/172.19.0.1:41281 Protocol options: explicit-exit-notify 1, protocol-flags cc-exit tls-ekm
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 TLS: soft reset sec=59/59 bytes=380/-1 pkts=10/0
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 VERIFY OK: depth=1, CN=Easy-RSA CA
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 VERIFY OK: depth=0, CN=user@example.com
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 peer info: IV_VER=2.6.0
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 peer info: IV_PLAT=mac
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 peer info: IV_TCPNL=1
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 peer info: IV_MTU=1600
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 peer info: IV_NCP=2
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 peer info: IV_PROTO=478
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 peer info: IV_LZO_STUB=1
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 peer info: IV_COMP_STUB=1
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 peer info: IV_COMP_STUBv2=1
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 peer info: IV_GUI_VER="net.tunnelblick.tunnelblick_5820_4.0.0beta02__build_5820)"
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 TLS: Username/auth-token authentication failed for username ''
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 Delayed exit in 5 seconds
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 SENT CONTROL [UNDEF]: 'AUTH_FAILED' (status=1)
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 SENT CONTROL [user@example.com]: 'AUTH_FAILED' (status=1)
tests-openvpn-1  | 2023-03-27 18:11:12 user@example.com/172.19.0.1:41281 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 256 bit ED25519, signature: ED25519
tests-openvpn-1  | 2023-03-27 18:11:17 user@example.com/172.19.0.1:41281 SIGTERM[soft,delayed-exit] received, client-instance exiting
jkroepke commented 1 year ago

... which @schwabe did not like (see discussion below the patch), but since nobody else seemed to be affected (... yet) this didn't progress. So we need to revisit this.

I propose an alternative solution in https://github.com/OpenVPN/openvpn/issues/299, which has way more benefits for SSO based logins and may could obsolete auth-token-user and resolve the caveats from that discussion.

jkroepke commented 1 year ago

I would like to know, if there an idea in mind which allowes to use auth-token-user, if the client username is empty?

jkroepke commented 1 year ago

I guess, this may be not getting fixed on the 2.6 track?

cron2 commented 1 year ago

There seems to be a bit of "post major release exhaustion" on the developers that mostly pushed the 2.6.0 release (@schwabe, @ordex, myself). I'm slowly picking up speed again, and I find this topic important to solve... but won't find time to do much in the next two weeks, so it won't get fixed for 2.6.5. But I will discuss with @schwabe to see how to move forward.

Sorry for the delay...

jkroepke commented 11 months ago

Hello, I would like to ask for an update here.

with deferred auth mechanism, its not necessary that client defines an own username, since the username/password authentication will be delegated to the browser.

However, with reneg-sec, the users have to re-authenticate each time. I would like to depend on OpenVPN auth-token mechanism which would be perfect in that use-case.

At the moment, https://github.com/jkroepke/openvpn-auth-oauth2 is a stateless service which does not hold client state. I would like to integrate any REAUTH logic there to keep the code clean.

jkroepke commented 10 months ago

@schwabe @cron2

Sorry for the ping here, but I would like to ask if there is an potential solution visible?

The authentication to each reg-sec interval is a big issue, since the Browser will be opened and if the user is still signed-in, the user is authenticated instantly. However, the OpenVPN 3 client breaks, if WebAuth is requested on REAUTH.

https://github.com/OpenVPN/openvpn3/issues/282

The only solution here is to configure a high reg-sec interval which leads to "insecure" workarounds.

jkroepke commented 6 months ago

I found a potential workaround here.

if

auth-gen-token <lifetime> external-auth

is defined, OpenVPN reports AuthenticatedEmptyUser to the management client. Then, its up to the management client to decide this as authenticated. Thats fits in my case here.