Yes, it breaks the connection. But I do have to admit this is using custom 2FA authentication running on the openvpn server.
The server has config including: ``` # Hand off to external process to initially authenticate users management "/var/run/openvpn/vpn3.sock" unix management-client-auth auth-gen-token 2592000 external-auth ``` And a daemon that read lines from the management interface (as per https://openvpn.net/community-docs/management-interface.html), handles strings with ">CLIENT:", and when required returns `"CRV1:R,E:%s:%s:Enter Verification Code"%(mfaState, b64username)` which triggers openvpn to request that data from the client. The client response then comes back to the daemon which can check the code is correct and notify the server that the client has authenticated. It breaks the VPN connection in that it can never get started - NM requests the password which progresses as normal, but as per the details above it fails to query the user for the MFA. NM thinks it has all the data so goes into a re-authentication loop. ``` 2026-03-04T12:08:40.931361+00:00 clienthostname nm-openvpn[538677]: OpenVPN 2.6.14 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] 2026-03-04T12:08:40.931841+00:00 clienthostname nm-openvpn[538677]: library versions: OpenSSL 3.0.13 30 Jan 2024, LZO 2.10 2026-03-04T12:08:40.931917+00:00 clienthostname nm-openvpn[538677]: DCO version: N/A 2026-03-04T12:08:41.125154+00:00 clienthostname nm-openvpn[538677]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 2026-03-04T12:08:41.128489+00:00 clienthostname nm-openvpn[538677]: TCP/UDP: Preserving recently used remote address: [AF_INET6]XXXX:1194 2026-03-04T12:08:41.128606+00:00 clienthostname nm-openvpn[538677]: UDPv6 link local: (not bound) 2026-03-04T12:08:41.128663+00:00 clienthostname nm-openvpn[538677]: UDPv6 link remote: [AF_INET6]XXXX:1194 2026-03-04T12:08:41.128717+00:00 clienthostname nm-openvpn[538677]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay 2026-03-04T12:08:41.161741+00:00 clienthostname nm-openvpn[538677]: [rvpn1] Peer Connection Initiated with [AF_INET6]XXXX:1194 2026-03-04T12:08:42.182214+00:00 clienthostname nm-openvpn[538677]: AUTH: Received control message: AUTH_FAILED,CRV1:R,E:mfa-jeremy-FZTNFBJ7OYM3TTPH:amVyZW15:Enter Verification Code 2026-03-04T12:08:42.182503+00:00 clienthostname nm-openvpn[538677]: SIGUSR1[soft,auth-failure] received, process restarting 2026-03-04T12:08:43.242264+00:00 clienthostname nm-openvpn[538677]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 2026-03-04T12:08:43.242420+00:00 clienthostname nm-openvpn[538677]: TCP/UDP: Preserving recently used remote address: [AF_INET6]XXXX:1194 ... (reconnections every second or so) ... 2026-03-04T12:09:41.077377+00:00 clienthostname nm-openvpn[538677]: [rvpn1] Peer Connection Initiated with [AF_INET6]XXXX:1194 2026-03-04T12:09:41.084014+00:00 clienthostname nm-openvpn[538677]: AUTH: Received control message: AUTH_FAILED,CRV1:R,E:mfa-jeremy-FZTNFBJ7OYM3TTPH:amVyZW15:Enter Verification Code 2026-03-04T12:09:41.084118+00:00 clienthostname nm-openvpn[538677]: SIGUSR1[soft,auth-failure] received, process restarting 2026-03-04T12:09:41.218512+00:00 clienthostname NetworkManager[1205]: <warn> [1772626181.2180] vpn[0x654c4dca9660,685536de-994c-419e-a34b-35eed81935d9,"jeremy_clienthostname"]: connect timeout exceeded 2026-03-04T12:09:41.220835+00:00 clienthostname nm-openvpn[538677]: SIGTERM[hard,init_instance] received, process exiting ``` And at this point (or in some circumstances sooner) nmcli has given up and shown an error. So here's the thing - I can fix this in my case by changing the response from "CRV1:R,E:" to "CRV1:R:". I still see some slight annoyances such as it saving the code (in the nmcli), but at least I get prompted for it and can delete the existing MFA code before re-adding it. I've built my own version of the client now to debug this, so I might see if upstream patch 02cbeba also fixes that for me (on top of cd279d4, 54613d3 and b45ecc1). Otherwise in terms of a proper reproduction case... Looking back at notes, our python auth daemon was tangentially based on the ideas from https://gist.github.com/selvanair/b31ec6d5873e2ffc141ec680fca69254. It also looks like I raised an related issue at https://community.openvpn.net/openvpn/ticket/1447 for the server running with NM on the client (which probably did get resolved in openvpn change `ddbe6a6f Fix auth-token usage with management-def-auth` but I already had my workaround by then). If that gist above isn't sufficient to go on for a reproduction, I can probably do a bit of work to clean up the daemon we have and put that on github. I've not found a great number of other projects using this, although at some point it seems like the commercial OpenVPN server did return CRV1:R,E: responses at least at one time for their Google Authenticator support - https://github.com/OpenVPN/openvpn-gui/issues/83. It looks like some other projects like https://github.com/jkroepke/openvpn-auth- oauth2 are now using the newer WEB_AUTH mechanism for bouncing via the browser. ** Bug watch added: community.openvpn.net/openvpn/ #1447 https://community.openvpn.net/openvpn/ticket/1447 ** Bug watch added: github.com/OpenVPN/openvpn-gui/issues #83 https://github.com/OpenVPN/openvpn-gui/issues/83 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2076101 Title: [SRU] Gnome openvpn saves authenticator code as password To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/2076101/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
