It's also worth mentioning that we are going to use the external-auth option for auth-gen-token as a workaround until the patch hits a release available in Ubuntu 22.04.
With this in our config, we can force the server to notify of reauths and we'll implement some code to check the session state to determine if the token is expired and the client should be disconnected instead. On Mon, Jul 4, 2022 at 10:34 AM Connor Edwards <connor.edwa...@b2c2.com> wrote: > Hello Selva, > > >This would lead to TLS keys going out of sync and eventual > client-disconnect as the auth will stay deferred forever. > >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. > Yep, this matches up with my observations. > > >Could you please post a full verb=4 server log using official community > releases for the client and server > I see you've sent a patch which is very much appreciated, so let me know > if you'd still like some logs. It looks like we've found the issue though. > > Any client can be used to reproduce it, it doesn't have to be Viscosity. > > Thanks > > On Sun, Jul 3, 2022 at 5:53 PM Selva Nair <selva.n...@gmail.com> wrote: > >> 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 >>> >> -- *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
