Opened 17 months ago

Last modified 17 months ago

#840 accepted Bug / Defect

Server --auth-gen-token and client --auth-nocache do not work together

Reported by: tincantech Owned by: David Sommerseth
Priority: minor Milestone:
Component: Configuration Version: OpenVPN 2.4.0 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

If a server pushes an auth-token to a client using auth-nocache the client does not cache the token. Thus renegotiating a connection after --reneg-sec/bytes/pkts causes client to drop the current connection and request password from user.

Currently the fix is: do not use --auth-nocache in client config.

More information:
https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg03511.html

Change History (2)

comment:1 Changed 17 months ago by David Sommerseth

Cc: David Sommerseth removed
Owner: set to David Sommerseth
Status: newaccepted

comment:2 Changed 17 months ago by David Sommerseth

Just documenting some test scenarios which must pass for a patch to be considered for inclusion.

Preparations

You need a simple authentication script. The example below should be sufficient:

#!/bin/bash
if [ "$password" = "pass123" ]; then
	echo "**** AUTH SUCCESSFUL"
	exit 0;
fi
echo "!!!!! AUTH FAILED: $password"
exit 1

Save this file and ensure it is executable.

The rest of the test scenarios expects a local git clone of the upstream source repositories.

Test 1: Default authentication

This is the simplest and probably most common script based authentication setups. The server will trigger a re-negotiation of the tunnel every 30th second.

Server: src/openvpn/openvpn --dev tun --server 10.8.0.0 255.255.255.0 --ca sample/sample-keys/ca.crt --key sample/sample-keys/server.key --cert sample/sample-keys/server.crt --dh sample/sample-keys/dh2048.pem --script-security 3 --auth-user-pass-verify auth.sh via-env --verb 4 --reneg-sec 30

Client: src/openvpn/openvpn --client --remote 192.168.122.1 --ca openvpn/sample/sample-keys/ca.crt --key openvpn/sample/sample-keys/client.key --cert openvpn/sample/sample-keys/client.crt --verb 4 --dev tun --auth-user-pass --ping 3 --ping-restart 6

Expected results

Using 'pass123' as the password, the connection should be established and renegotiated automatically at least every 30th second. When renegotiation happens, the client should continue to run as before. Any other passwords should fail.

Test 2: Default authentication with no cached password

Basically the same setup as Test 1, but this time the client will not cache the user's password.

Server: src/openvpn/openvpn --dev tun --server 10.8.0.0 255.255.255.0 --ca sample/sample-keys/ca.crt --key sample/sample-keys/server.key --cert sample/sample-keys/server.crt --dh sample/sample-keys/dh2048.pem --script-security 3 --auth-user-pass-verify auth.sh via-env --verb 4 --reneg-sec 30

Client: src/openvpn/openvpn --client --remote 192.168.122.1 --ca openvpn/sample/sample-keys/ca.crt --key openvpn/sample/sample-keys/client.key --cert openvpn/sample/sample-keys/client.crt --verb 4 --dev tun --auth-user-pass --ping 3 --ping-restart 6 --auth-nocache

Change from Test1: Client have added --auth-nocache

Expected results

Using 'pass123' as the password, the connection should be established and renegotiated automatically at least every 30th second. When renegotiation happens, the client will ask for username/password again. Using any other password should fail.

Test 3: Token based authentication

This is a variant of Test 1, where the user sends username/password as normal. The server sends an authentication token back to the client which replaces the locally cached password. This token is used on the following renegotiations.

Server: src/openvpn/openvpn --dev tun --server 10.8.0.0 255.255.255.0 --ca sample/sample-keys/ca.crt --key sample/sample-keys/server.key --cert sample/sample-keys/server.crt --dh sample/sample-keys/dh2048.pem --script-security 3 --auth-user-pass-verify auth.sh via-env --verb 4 --reneg-sec 30 --auth-gen-token

Client: src/openvpn/openvpn --client --remote 192.168.122.1 --ca openvpn/sample/sample-keys/ca.crt --key openvpn/sample/sample-keys/client.key --cert openvpn/sample/sample-keys/client.crt --verb 7 --dev tun --auth-user-pass --ping 3 --ping-restart 6

Change from Test 1: Server have added --auth-gen-token. Client have increased logging to --verb 7.

Expected results

Using 'pass123' as the password, any other passwords should fail. The server should send a PUSH_REPLY containing 'auth-token' with a random token. This should be seen in the client log. The connection should be established and renegotiated automatically at least every 30th second, but using the token instead of the password. The auth.sh script will only be called once. When renegotiation happens, the client should continue to run as before.

Sub-test 3A

Stop the server process while the client is connected and restart it with the same arguments. The client should reconnect but authentication should fail due to incorrect password (which is reported by the script)

Test 4: Token based authentication with --auth-nocache

This is a variant of Test 3, where the user sends username/password as normal. The server sends an authentication token back to the client which replaces the locally cached password. This token is used on the following renegotiations. But the client is configured to not cache any passwords - which should be overridden when the server sends the PUSH_REPLY containing an auth-token.

Server: src/openvpn/openvpn --dev tun --server 10.8.0.0 255.255.255.0 --ca sample/sample-keys/ca.crt --key sample/sample-keys/server.key --cert sample/sample-keys/server.crt --dh sample/sample-keys/dh2048.pem --script-security 3 --auth-user-pass-verify auth.sh via-env --verb 4 --reneg-sec 30 --auth-gen-token

Client: src/openvpn/openvpn --client --remote 192.168.122.1 --ca openvpn/sample/sample-keys/ca.crt --key openvpn/sample/sample-keys/client.key --cert openvpn/sample/sample-keys/client.crt --verb 4 --dev tun --auth-user-pass --ping 3 --ping-restart 6 --auth-nocache

Change from Test 3: Client have decreased logging to --verb 4 and added --auth-nocache

Expected results

Using 'pass123' as the password, any other passwords should fail. The server should send a PUSH_REPLY containing 'auth-token' with a random token. The connection should be established and renegotiated automatically at least every 30th second, but using the token instead of the password. The auth.sh script will only be called once. When renegotiation happens, the client should continue to run as before.

Sub-test 4A

Stop the server process while the client is connected and restart it with the same arguments. The client should reconnect but authentication should fail due to incorrect password (which is reported by the script)

Test 5: Token based authentication where the script generates the token

Reuse Test 3 but the auth.sh script must be modified to generate an authentication token and save that in a dynamically generated CCD file as a push "auth-token $value" line. The server configuration needs to remove --auth-gen-token. The generated token value should also be accepted as a valid password.

Expected results

The test should have the same results as Test 3, with the exception that the auth.sh script is called on every re-negotiation. The initial password should change to the generated auth-token on all the re-negotiations.

Test 6: Token based authentication where the script generates the token with --auth-nocache

Reuse Test 4, but the auth.sh script from Test 5. The server configuration needs to remove --auth-gen-token. The client needs to add --auth-nocache.

Expected results

The test should have the same results as Test 4, with the exception that the auth.sh script is called on every re-negotiation. The initial password should change to the generated auth-token on all the re-negotiations.

Last edited 17 months ago by David Sommerseth (previous) (diff)
Note: See TracTickets for help on using tickets.