OpenVPN
Openvpn3 indicator does not support 2fa authentication profile
Currently openvpn3-indicator does not support 2fa authentication profiles, openvpn3 cli does support it
though openvpn3 sessions-list returns with current session, but as 2fa code is not asked can't ssh to specified server address
Are you sure you're running the latest version? I've been testing that against OpenVPN Access Server with a profile requiring 2FA ...
What kind of server do you connect against?
@pushkargogte Did you store credentials? If you did, then the app stored the code and tries to use the old one. I need to fix this. You can try removing configuration and importing it again. Then it will not use old credentials.
@dsommers I don't have a profile with 2FA to test against. Can I set it up using openvpn2 server? Do you have any hints how to tell which fields should never be stored in secret storage?
@pushkargogte Did you store credentials? If you did, then the app stored the code and tries to use the old one. I need to fix this. You can try removing configuration and importing it again. Then it will not use old credentials.
yes i'm using config imported in openvpn3-cli
my .ovpn config file does have stored credentials
@dsommers I don't have a profile with 2FA to test against. Can I set it up using openvpn2 server? Do you have any hints how to tell which fields should never be stored in secret storage?
@grzegorz-gutowski I'll reach out via e-mail with details.
@pushkargogte You can try the newest version. It is not the final solution yet (as I yet have to write some code that decides which fields are unsafe for storage), but it could get you going (with an unnecessary, failing authorization attempt with an old Auth Code)
@pushkargogte You can try the newest version. It is not the final solution yet (as I yet have to write some code that decides which fields are unsafe for storage), but it could get you going (with an unnecessary, failing authorization attempt with an old Auth Code)
i tried newest version available in launchpad, but it not working
can you share me your email address as the video recording consists of confidential info? can you also give undertaking to not share confidential info?
You can share the recording to my e-mail adress [email protected].
I will not share it, and keep it confidential.
Please, run openvpn3-indicator --debug in terminal, to give more debugging information.
You can share the recording to my e-mail adress [email protected]. I will not share it, and keep it confidential. Please, run
openvpn3-indicator --debugin terminal, to give more debugging information.
have sent you the video recordings
It seems that indicator does not handle dynamic challenges to well. @dsommers : can you please comment on how dynamic challenge is different from regular authorization? From the first reading it seems to me, that they both end in CONNECTION:CFG_REQUIRE_USER status. And should be handled the same way from there, but there has to be some difference.
You can share the recording to my e-mail adress [email protected]. I will not share it, and keep it confidential. Please, run
openvpn3-indicator --debugin terminal, to give more debugging information.
@grzegorz-gutowski can you check your email, I have emailed you the logs
@grzegorz-gutowski Okay, so this whole authentication scheme is a complicated mess ... as there are more ways how this is handled, mostly for historical reasons.
The low-level aspects of the static/dynamic challenges are documented here: https://github.com/OpenVPN/openvpn/blob/master/doc/management-notes.txt#L1209
-
static challenge: This is triggered by the
static-challengeoption in the client configuration. The challenge is here requested before connecting to the server -
dynamic challenge: The server sends an auth-failed message with a "CRV1" message parsed by the client (
openvpn3-service-clientprocess). The client will in this case disconnect from the server, but the session is still valid in the session manager - with theCFG_REQUIRE_USERstatus. Since the server sends theAUTH_FAILEDmessage, the D-Bus call will result in an exception being thrown in theConnect()call. That's why you see this "hack" in theopenvpn2Python wrapper; also notice thewhileloop and thedoneboolean flag in line 238. The "good thing" is that you don't need to care about the low-level stuff here, but you will need to do a newReady()+Connect()call. -
authentication pending: This is used by the web based authentications, but can also be used in other contexts. This differs from the dynamic challenge that it does not disconnect from the server; the client will continuously poll the server with "PULL_REQUEST" until the server either accepts or rejects the client. The client can in this phase also send a "challenge response" back to the server. In this case,
StatusChangecan be more useful, as seen in line 139.
The Ready() call is there to actually catch if you need to do interact with the end-user; so you know you have everything needed before you can call Connect().
OpenVPN Access Server and Cloud Connexa have moved towards using just the "pending auth" approach, but we still need to support all methods. Older Access Servers will not do the "auth pending" approach, neither will many community server setups.
In the Access Server config you got, you can dump that (openvpn3 config-dump) and re-import it without the static-challenge option. I don't recall now if the current AS installation will resort to "dynamic challenge" or "auth pending" .... but in both cases, the D-Bus implementation should basically be the same. The main difference is that you will get a StatusChange signal requesting more user input with the auth pending approach. I'll see if I can cook up a server config to test the older "dynamic challenge" approach.
I wish it would be simpler ways to do this - but so far there has been some challenges with getting D-Bus signals properly delivered with the "dynamic challenge" approach due to the client thread is being stopped automatically and outside of the control of the OpenVPN 3 Linux implementation. This may improve in later releases, since the GDBus++ implementation in the coming v22_dev release can behave a bit different in regards to how and when signals are sent.
@dsommers I tried AS config of yours with removed static-challenge as you suggested. This scenario indeed resorts to dynamic challenge and works pretty well - secret storing is still flawed, but the connection goes through. I get CFG_REQUIRE_USER twice with different inputs, so indicator displays the login dialog twice, as I would expect it to.
@pushkargogte Can you please share some more details of your setup?
@dsommers I tried AS config of yours with removed
static-challengeas you suggested. This scenario indeed resorts to dynamic challenge and works pretty well - secret storing is still flawed, but the connection goes through. I get CFG_REQUIRE_USER twice with different inputs, so indicator displays the login dialog twice, as I would expect it to. @pushkargogte Can you please share some more details of your setup?
i have mailed you a sample ovpn file with the configuration i use
Issue is resolved after updating openvpn3-linux package to v21 @dsommers if possible can you add a note to reconfigure openvpn3 repo with new links mentioned in https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux for those who have already installed v20 on their machine, here https://github.com/OpenVPN/openvpn3-linux/releases/tag/v21?
@pushkargogte We should probably highlight that, yes ... thanks for the heads-up!
Even though, with the latest change from me merged .... I would expect v20 to work though ... but maybe it's something else too.
@pushkargogte We should probably highlight that, yes ... thanks for the heads-up!
Even though, with the latest change from me merged .... I would expect v20 to work though ... but maybe it's something else too.
There's more investigation needed, as after upgrading to v21, openvpn3-indicator failed
On second try it started working I have sent the videos capturing logs to greg
My guess is that the cause of the problem is that sometimes indicator does not get status change to CFG_REQUIRE_USER. In v20 it looked as if indicator got CFG_REQUIRE_USER for the user/password prompt, then after providing credentials and connecting comes dynamic challenge, and indicator does not get new status change and stays in "old" CFG_REQUIRE_USER. In v21 in the faulty run that pushkargogte mentions, after connect it got status change to CONN_CONNECTING, and stayed in that state forever.