Openvpn3 indicator does not support 2fa authentication profile

pushkargogte commented 2 months ago

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

dsommers commented 2 months ago

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?

grzegorz-gutowski commented 2 months ago

@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.

grzegorz-gutowski commented 2 months ago

@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 commented 2 months ago

@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 commented 2 months ago

@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.

grzegorz-gutowski commented 2 months ago

@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 commented 2 months ago

@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?

grzegorz-gutowski commented 2 months ago

You can share the recording to my e-mail adress grzegorz.gutowski@uj.edu.pl. I will not share it, and keep it confidential. Please, run openvpn3-indicator --debug in terminal, to give more debugging information.

pushkargogte commented 2 months ago

You can share the recording to my e-mail adress grzegorz.gutowski@uj.edu.pl. I will not share it, and keep it confidential. Please, run openvpn3-indicator --debug in terminal, to give more debugging information.

have sent you the video recordings

grzegorz-gutowski commented 2 months ago

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.

pushkargogte commented 2 months ago

You can share the recording to my e-mail adress grzegorz.gutowski@uj.edu.pl. I will not share it, and keep it confidential. Please, run openvpn3-indicator --debug in terminal, to give more debugging information.

@grzegorz-gutowski can you check your email, I have emailed you the logs

dsommers commented 2 months ago

@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-challenge option 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-client process). The client will in this case disconnect from the server, but the session is still valid in the session manager - with the CFG_REQUIRE_USER status. Since the server sends the AUTH_FAILED message, the D-Bus call will result in an exception being thrown in the Connect() call. That's why you see this "hack" in the openvpn2 Python wrapper; also notice the while loop and the done boolean 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 new Ready() + 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, StatusChange can 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.

grzegorz-gutowski commented 2 months ago

@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?

pushkargogte commented 2 months ago

@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?

i have mailed you a sample ovpn file with the configuration i use

pushkargogte commented 2 months ago

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?

dsommers commented 2 months ago

@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 commented 2 months ago

@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

pushkargogte commented 2 months ago

Was closed by mistake

grzegorz-gutowski commented 2 months ago

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.

OpenVPN / openvpn3-indicator

Openvpn3 indicator does not support 2fa authentication profile #7