id summary reporter owner description type status priority milestone component version severity resolution keywords cc 847 "Long lived crypto ""state"" client lock-up" David Sommerseth Steffan Karger "== Configuration setup == === Client === `[root@localhost ~]# openvpn --client --remote 192.168.122.1 --ca sample/sample-keys/ca.crt --key sample/sample-keys/client.key --cert sample/sample-keys/client.crt --verb 4 --dev tun --auth-user-pass --explicit-exit-notify --auth-nocache` === Server === `[root@localhost ~]# openvpn --dev tun --ca sample/sample-keys/ca.crt --key sample/sample-keys/server.key --cert sample/sample-keys/server.crt --dh sample/sample-keys/dh2048.pem --server 10.8.0.0 255.255.255.0 --script-security 3 --auth-user-pass-verify .auth.sh via-env --verb 7 --reneg-sec 10` == What happens == The client asks for username/password, connects and running ping on the client against 10.8.0.1 works as expected. A renegotiation is forced (due to `--reneg-sec 10`). At this point '''do not''' enter any credentials until the server have logged: {{{ Sat Feb 25 00:34:55 2017 us=576093 Test-Client/192.168.122.9:1194 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Sat Feb 25 00:34:55 2017 us=576099 Test-Client/192.168.122.9:1194 TLS Error: TLS handshake failed Sat Feb 25 00:34:55 2017 us=576104 Test-Client/192.168.122.9:1194 TLS: move_session: dest=TM_LAME_DUCK src=TM_ACTIVE reinit_src=1 }}} When this stage is completed, enter the proper username/password credentials. The client will re-connect properly (might need a couple of attempts, due to some client time-outs). But from this point of the server will no longer accept packets on the DATA channel from the client. Right before the rejection happens, this can be seen in the server log: {{{ Sat Feb 25 00:35:06 2017 us=972360 Test-Client/192.168.122.9:1194 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Sat Feb 25 00:35:06 2017 us=972379 Test-Client/192.168.122.9:1194 Data Channel Encrypt: CIPHER KEY: 3d4f9143 557d88ff 51cf05f7 4052abd8 93126d2e f2c1826c 1a7888a2 ef3cceb8 Sat Feb 25 00:35:06 2017 us=972401 Test-Client/192.168.122.9:1194 Data Channel Encrypt: CIPHER block_size=16 iv_size=12 Sat Feb 25 00:35:06 2017 us=972424 Test-Client/192.168.122.9:1194 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Sat Feb 25 00:35:06 2017 us=972449 Test-Client/192.168.122.9:1194 Data Channel Decrypt: CIPHER KEY: e8c6b960 88e078da ce001f18 8f465bb0 bc82adfa 63118cd3 7d29d6b1 70273ae4 Sat Feb 25 00:35:06 2017 us=972465 Test-Client/192.168.122.9:1194 Data Channel Decrypt: CIPHER block_size=16 iv_size=12 Sat Feb 25 00:35:06 2017 us=972540 Test-Client/192.168.122.9:1194 UDPv4 WRITE [247] to [AF_INET]192.168.122.9:1194: P_CONTROL_V1 kid=0 [ 5 ] pid=6 DATA len=221 }}} And after that, the following log lines appears for each packet the client tries to send over the VPN tunnel {{{ Sat Feb 25 00:35:06 2017 us=972653 Test-Client/192.168.122.9:1194 AEAD Decrypt error: cipher final failed }}} The bad thing about this is that this is persistent if the client stops its openvpn process (even with `--explicit-exit-notify`) and starts a completely fresh session. Restarting the server side re-enables the client again. " Bug / Defect new major Crypto OpenVPN 2.3.10 (Community Ed) Not set (select this one, unless your'e a OpenVPN developer) tct Gert Döring