Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
jkroepke opened this issue Mar 23, 2023 · 20 comments
Open

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

jkroepke opened this issue Mar 23, 2023 · 20 comments

Comments

@jkroepke
Copy link

jkroepke commented Mar 23, 2023 •
edited
Loading

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

  • OS: Ubuntu 22.04
  • OpenVPN version: 2.6.1 [git:release/2.6/e950ca1b9fca58e9]
  • Repeat for peer if relevant

Client

  • OS: Windows 10
  • OpenVPN version: 2.6.1

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

selvanair commented Mar 25, 2023 •
edited
Loading

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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Author

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
Copy link
Contributor

selvanair commented Mar 25, 2023 •
edited
Loading

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

cron2 commented Mar 27, 2023 via email •
edited
Loading

@jkroepke
Copy link
Author

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 jkroepke mentioned this issue Mar 27, 2023
Open
@jkroepke
Copy link
Author

... 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 #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
Copy link
Author

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
Copy link
Author

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

@cron2
Copy link
Contributor

cron2 commented May 20, 2023

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
Copy link
Author

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 jkroepke mentioned this issue Sep 22, 2023
Closed
@jkroepke
Copy link
Author

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

OpenVPN/openvpn3#282

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

@jkroepke jkroepke mentioned this issue Nov 17, 2023
Closed
@jkroepke jkroepke mentioned this issue Dec 21, 2023
Closed
@jkroepke jkroepke mentioned this issue Feb 5, 2024
Closed
This was referenced Feb 19, 2024
Closed
Closed
@jkroepke
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Feature: Add Support for Custom auth-token validation ihipop/openvpn-auth-oauth2
3 participants
@jkroepke @cron2 @selvanair