| Summary: | Selecting OTP does not add correct directives to ovpn file | ||
|---|---|---|---|
| Product: | IPFire | Reporter: | Greg Ramey <emptythevoid> |
| Component: | --- | Assignee: | Michael Tremer <michael.tremer> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | Minor Usability | ||
| Priority: | - Unknown - | CC: | adolf.belka, michael.tremer |
| Version: | 2 | ||
| Hardware: | x86_64 | ||
| OS: | All | ||
|
Description
Greg Ramey
2023-01-06 16:20:48 UTC
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. |