Hi, On Sat, Jul 2, 2022 at 6:20 PM Connor Edwards via Openvpn-users < openvpn-users@lists.sourceforge.net> wrote:
> 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. > The above difference in behaviour rings a bell. I had noticed a similar misbehaviour in 2.6 (possibly also present in 2.5) that is very likely a bug. I looked into it again: On reauth, after auth token verification success, the log shows: test/127.0.0.1:35874 TLS: Username/auth-token authentication succeeded for username 'test' test/127.0.0.1:35874 TLS: Username/Password authentication deferred for username 'test' [CN SET] The "authentication deferred" line above results from the use of management-def-auth, but the management interface will not be notified in this case as auth-token bypasses it during reauth. This would lead to TLS keys going out of sync and eventual client-disconnect as the auth will stay deferred forever. Plugin and script based auths are not affected. The auth-token expiry message you see may be an indirect effect of this --- the server first disconnects the client, while the client continues and eventually does a ping-restart with the old token which will have a timestamp out of the reneg interval.. Could you please post a full verb=4 server log using official community releases for the client and server --- tunnelblick as client should be okay. It's not possible for us to reproduce what a viscosity client or server may be doing. Selva > > 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 > <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 >
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
