Right, I think I'm getting somewhere with this now. It's not the OpenVPN server version, it seems to be something to do with the management socket options.
I mentioned that we have this in the config: >management /run/openvpn/server/management.sock unix >management-client-auth If I comment those lines out and add a verify script to just let any user in: >auth-user-pass-verify /verify.sh via-env There's no issues and the client stays connected through TLS reauths. Logically you might think that the reason the clients are being kicked off after a minute or so with management-client-auth is because another command needs to be entered to allow reauth. But in this case the server does not inform of reauth over the socket. >client-auth-nt 0 0 >>CLIENT:ESTABLISHED,0 ... >>CLIENT:DISCONNECT,0 I'm aware that external-auth can be appended to the auth-gen-token option to handoff auth so that the server doesn't verify the token internally. This isn't what we're looking for - we want the server to handle the auth token generation and verification internally otherwise we'll have to implement this ourselves. There's nothing in the docs that says this is mutually exclusive with using the management socket. >auth-gen-token 43200 external-auth Thanks On Sat, Jul 2, 2022 at 5:07 PM Connor Edwards <connor.edwa...@b2c2.com> wrote: > Hello David, > > Yep, I have had a look at the source and the auth token feature was > overhauled in v2.5.0. > > This issue is reproducible with the Viscosity client for macOS which uses > v2.5.5 under the hood. But so far in my testing the client version doesn't > seem to matter, only the server version does. > > My colleague and I have pored over the docs/manpage/source code but we > haven't been able to find why this is happening. We are using a token > lifetime of 12 hours: > >auth-gen-token 43200 > > Yet upon a client connecting, the server will log that the token is > expired not even a few minutes later. > > Here is a fairly minimal server/client config that can reproduce it. Note > that reneg-sec is set to 30 for demonstration of this issue only. > > server.conf > >topology subnet > >server 192.168.254.0 255.255.255.0 > >port 443 > >proto tcp > >dev tun > >user openvpn > >group openvpn > >ca /etc/openvpn/pki/ca.crt > >cert /etc/openvpn/pki/issued/server.crt > >key /etc/openvpn/pki/private/server.key > >tls-server > >tls-crypt /etc/openvpn/ta.key > >tls-cert-profile preferred > >cipher AES-256-GCM > >remote-cert-tls client > >verify-client-cert require > >auth SHA512 > >dh none > >ifconfig-pool-persist ipp.txt > >keepalive 10 120 > >persist-key > >persist-tun > >management /run/openvpn/server/management.sock unix > >management-client-auth > >reneg-sec 30 > >auth-gen-token 43200 > > client.conf > >remote localhost 443 tcp-client > >nobind > >dev tun > >redirect-gateway def1 ipv6 > >persist-key > >pull > >auth-user-pass > >tls-client > >ca ca.crt > >cert cert.crt > >key key.key > >remote-cert-tls server > >tls-crypt tlscrypt.key > >auth SHA512 > >push-peer-info > >cipher AES-256-GCM > > Steps to reproduce: > > 1. Install OpenVPN server 2.5.5 > 2. Connect to the server management socket with nc > -U /run/openvpn/server/management.sock > 3. Connect the client to the server > 4. Issue the client-auth-nt command in to the socket to allow the > connection, for example: client-auth-nt 0 0 > 5. Watch the server logs > 6. Observe that the client is disconnected for an expired token a few > minutes later > > After about a minute, I see this: > >127.0.0.1:57834 --auth-token-gen: auth-token from client expired > >127.0.0.1:57834 TLS: Username/auth-token authentication failed for > username '...' > >127.0.0.1:57834 Connection reset, restarting [0] > > Any ideas? > > Thanks > > On Thu, Jun 30, 2022 at 8:44 PM David Sommerseth < > open...@sf.lists.topphemmelig.net> wrote: > >> On 30/06/2022 12:37, Connor Edwards via Openvpn-users wrote: >> > Hello, >> > >> > We are looking into using auth-gen-token on our new VPN server which >> > will be using version 2.5.5. However, we've noticed that the behaviour >> > of auth-gen-token has changed and our clients are being kicked off >> every >> > hour which corresponds with the renegotiation interval (3600 secs). >> > >> > >127.0.0.1:57748 <http://127.0.0.1:57748> --auth-token-gen: >> auth-token >> > from client expired >> > >> > On our existing VPN server which uses 2.4.7, clients are able to stay >> > connected up to 12 hours with an auth token and this is not affected by >> > the renegotiation interval. In 2.5.0 an additional auth token check was >> > added that seems to limit the token lifetime to as long as the >> > renegotiation interval, but we don't understand what this is for. >> >> It's a long while since I dug into the auth-gen-token code paths, but I >> have some vague memories we did quite some enhancements on that feature >> in OpenVPN 2.5. >> >> I recommend you to have a look at the man page, that should be >> up-to-date. In particular the 'lifetime' argument would be relevant for >> you. >> >> <https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html> >> >> Which version of OpenVPN are your clients running? >> >> >> -- >> kind regards, >> >> David Sommerseth >> OpenVPN Inc >> >> -- *This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you must not disseminate, distribute or copy this e-mail. Please notify us on regulat...@b2c2.net <mailto:regulat...@b2c2.net> immediately if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.*
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
