When a new user is added to OpenVPN and OTP is checked, two required directives are not added to the resulting ovpn file. The two lines are required to prompt the user to enter their OTP: auth-user-pass static-challenge "Enter your OTP" 0 Manually adding these to the ovpn file allows normal operation, so I believe the issue is that IPFire doesn't add them into the ovpn file it generates. This is reproducible.
Hey Greg, do you have more details about this? I cannot reproduce it.
I'm hoping this is something I've done wrong, since I'm still figuring things out. But I've run into this twice. Here's what happened. In IPFire, I have an OpenVPN server setup. I used the option to enable OTP on an OpenVPN account. I scanned the QR code to Google Authenticator. On Windows, I'm using the OpenVPN Community client. I've imported the ovpn file. When I choose to connect, it gets stuck at a MANAGEMENT: >STATE:.....WAIT...., which eventually times out with a TLS negotiation failed. I'm not prompted to enter my OTP code. It's only after I add the two directives that the OTP prompt appears and I can enter it. It may be relevant to specify that I'm using the insecure ovpn file that includes the CA, cert, and key. Here is a sample ovpn file that is generated by IPFire, with the crypto stuff removed for brevity. It does not include the two lines I've been adding. #OpenVPN Client conf tls-client client nobind dev tun proto udp tun-mtu 1400 remote ipfire.localdomain 1194 ;ca cacert.pem ;cert testotp2.pem ;key testotp2.key cipher AES-256-CBC auth SHA512 verb 3 remote-cert-tls server verify-x509-name ipfire.localdomain name mssfix 0 auth-nocache auth-token-user USER auth-token TOTP auth-retry interact <ca> -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- </ca> <cert> Bag Attributes friendlyName: testotp2 localKeyID: 9B 96 2A B2 63 FF 09 CF A9 53 39 47 10 64 58 23 91 06 21 99 subject=C = US, O = greg, CN = testotp2 issuer=C = US, O = greg, CN = greg CA -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- </cert> <key> Bag Attributes friendlyName: testotp2 localKeyID: 9B 96 2A B2 63 FF 09 CF A9 53 39 47 10 64 58 23 91 06 21 99 Key Attributes: <No Attributes> -----BEGIN PRIVATE KEY----- ... -----END PRIVATE KEY----- </key> #--------------------------- # Start of custom directives # from client.conf.local #--------------------------- #--------------------------- # End of custom directives #---------------------------
Hold tight for a moment. I may have another variable that's interfering.
Sorry sorry. I just blew away both my IPFire instance and my Windows client instance and started completely from scratch. The error I'm getting when attempting to use OTP using an insecure ovpn file is SENT CONTROL PUSH_REQUEST status=1. I'm not asked for an OTP code. Only after I add those two directives to the ovpn file does it ask me to the OTP code and connect successfully.
That should read "It's not asking for an OTP code"
Here's video of what happens without and with the directives added. https://www.youtube.com/watch?v=CRBFC9oOql8
(In reply to Michael Tremer from comment #1) > Hey Greg, > > do you have more details about this? I cannot reproduce it. We're both using the OpenVPN GUI and not OpenVPN Connect, yes?
Did more reading. I *think* the static-challenge directive is forcing the OTP prompt to appear. I think what's supposed to happen is openvpn is supposed to send an error message to force the client to do auth-retry interactive, which is supposed to allow entering the OTP. This doesn't seem to happen for me, on either Community or Connect.
Had a chance to stare at the the client log. I can see where the "fake" login fails. The log shows a control message "AUTH_FAILED....:One Time Token:" and then a reconnect. It completes a MANAGEMENT: >STATE....,GET_CONFIG and then gets stuck on PUSH_REQUEST (status=1)
This is the issue I'm hitting!! Bah, sorry, it's an issue with the OpenVPN Community client! I'm sorry for the hassle. https://community.ipfire.org/t/cu-171-with-totp/8964 Using client 2.5.7 allows the OTP code prompt to appear correctly without any additional configuration. 2.5.8 requires the two directives specified. For anyone else seeing this, the two directives I mention seem to work around this problem.
As you have indicated this was an issue with the client I am closing this bug. If it is still valid then it can be re-opened and more information provided.