@ummeegge (and everyone else as well). Reading the documentation I found a sentence suggesting that if both --auth-token and --auth-user-pass-verify are enabled, the server will ask for username and password and it will expect to receive as password the TOTP token.
Quote:
–auth-token token This is not an option to be used directly in any configuration files, but rather push this option from a –client-connect script or a –plugin which hooks into the
[…]
Whenever the connection is renegotiated and the --auth-user-pass-verify script or --plugin making use of the OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY hook is triggered, it will pass over this token as the password instead of the password the user provided.
[…]
The purpose of this is to enable two factor authentication methods, such as HOTP or TOTP, to be used without needing to retrieve a new OTP code each time the connection is renegotiated.
Is it possible that we need this option to allow the 2FA with the mobile clients, including OpenVPN for Android (Arne Schwabe community fork). In particular, this client from what I have gathered should be able to authenticate with a second factor. Could it be that both, this clien and even OpenVPN Connect as well uses this method to prompt the user?
In IPFire --auth-user-pass-verify is not offered as an option. Could it be that it should be offered to allow a 2FA on all clients?
Hi @cfusco ,
haven´t observed the whole 2FA development and do not use it currently but as far as i can see the ‘–auth-token’ directive takes already place in client.ovpn and a corresponding ‘–auth-user-pass-optional’ is located in server.conf . What i noticed is that the server.conf includes a ‘reneg-sec 86400’ (one day instead of the old default of one hour) even i do not use 2FA which is a problem since in fact this one disables the PFS and an important layer of security ?! May can someone confirm ?
Also, to prevent exactly this (disable one security aspect to enable another one) i think the option ’ –auth-gen-token’ → [Openvpn-devel] [PATCH v2 0/4] New feature: --auth-gen-token has been made but am currently not sure if you can use it only without ‘–auth-nocache’ which is also located in client.ovpn .
@ummeegge Thanks for the reply. Like you, I also do not use 2FA but I am curious and IPFire users seem to want this feature. So I tried to the best of my ability to understand the issue (which doesn’t say much, but I am doing my best) just so that I can answer accurately when this is questioned here in the forum.
I first assumed that the clients, with the exception of the community edition for windows, do not support yet the feature. But then, I researched the alternative client for Android and from what I can gather it is supposed to work by asking for username and password, where the password is the token. Then I read the documentation regarding the use --auth-user-pass-verify in the OTP context (reported in my previous message) which seems to confirm the hypothesis that the clients can already handle 2FA. Finally, I went over Opensense and saw that they do support OTP and in their documentation they imply that OpenVPN connect will work with their scheme. Which is Username and [OTP token+password] in the password field, plus a different certificate per user, as in IPFire. Basically they have implemented a three factor authentication for OpenVPN.
I strongly suspect that the server should have a script called by --auth-user-pass-verify to handle the password exchange, and if --auth-token is active, it will prompt OpenVPN Connect to ask for username and password whereby the password will be the token. This of course would happen in addition to importing and using the certificate (which it is already working fine in all clients) creating a multi-factor authentication.
I lack the ability to test myself the hypothesis. I just hope someone with the right skills can look in to this. Again, just to satisfy my curiosity (selfish) but also because IPFire users want this feature which is supported by a prominent IPFire competitor and, more importantly, to give a correct information to the users on why 2FA is NOT working for them, even if it is implied by the wiki documentation that it should.
At the very least, we should properly document the use of 2FA in the wiki. As it is, it generates only confusion. I can do that, but first I need to know how things work in reality, and I went as far as I can in my investigation.
Hello @cfusco,
try to step by step through your questions.
Understand that, it might also be an idea if the know how comes up to update the wiki ?
You can find in here → wiki.ipfire.org - Multi-factor authentication (2FA) clients which do support TOTP for 2FA for every platform (not sure if this list is complete).
The ‘–auth-user-pass-verify’ directive in server.conf requires all clients to authenticate therefor, ‘–auth-user-pass-optional’ was used in server.conf since you can use OTP in IPFire client specific and not global. We did it longer time ago in the OpenSense way in a longer testing period but therefor you would need a specific user database for authentication like PAM and in that case users from passwd (useradd). IPFire does not provide a user authentication database but uses the certificate common name as ‘username’ and TOTP as password instead.
If you click on the OTP symbol for enabled 2FA clients in “Client Status and -Control” you get the oathtool secret and the QR-Code which delivers the password(s)
Where are the problems for the users ? Most of the authentication logic does openvpn-authenticator where i have read about some processing problems but also about some patches/fixes.
A problem for me is not all that new configuration directives in the config files even i did NOT configured 2FA cause they will be ignored by openvpn-authenticator but the line in server.conf
reneg-sec 86400
will be globally used and no matter if you have one/multiple or NO OTP clients like me this line breaks the “Perfect Forward Secrecy” which is in my opinion a bug…
Just one clarification, I am aware of that wki page. I believe I have read the entire wiki more than once. Here you and I are probably talking past each other.
Let me try to clarify my point. Those are apps to generate a time-based token. Fine, I use them, I know about them. I am NOT talking about that. What I am saying is that - with the exception of the OpenVPN CLIENT in the Windows community edition - all the other clients based on OpenVPN Connect DO NOT WORK for the user when configuring the 2FA, as they do not give you a way to input the OTP token.
Do you acknowledge that this is true? Or do I get this wrong?
As I said, I thought that the OTP feature was not YET implemented in the code of the clients, but now I have come to doubt that and suspect also that given how the server is configured by IPFire, they never will. This is because the code might be there and simply we do not configure the server in the way the clients expects to be told how to send the token, by presenting the request of USERNAME and PASSWORD.
Having said that, I need to read you answer with full attention to understand what you are telling me, as I just superficially skimmed trough the text. I wanted at the moment just to try to clarify where I am coming from with the assertion that the clients (OpenVPN clients) do not work porperly due to how OpenVPN server is configured in IPFIre. I am not saying that I am right. Probably I am not. I am just trying to explain my point so that it can be understood.
I wish also to thank you for spending your precious time to discuss this issue with me. This on the top of the work you did for giving the users of IPFire the possibility of using their own VPN.
I will give you a more thoughtful answer when I manage to understand your points.
OK i see. Made a fast one. If i use ‘auth-user-pass’ on client side, i get an
2023-03-23 13:53:50 [ipfire.local] Peer Connection Initiated with [AF_INET]192.168.234.1:1194
2023-03-23 13:53:52 SENT CONTROL [ipfire.local]: 'PUSH_REQUEST' (status=1)
2023-03-23 13:53:52 AUTH: Received control message: AUTH_FAILED,CRV1:R,E:dGVzdG5vZXhwaXJpbmdydw==:VE9UUA==:One Time Token:
2023-03-23 13:53:52 SIGUSR1[soft,auth-failure (auth-token)] received, process restarting
2023-03-23 13:53:52 Restart pause, 5 second(s)
CHALLENGE: One Time Token:
so the “CHALLENGE” from openvpn-authenticator comes up whereby i entered the 6 digit OTP and failed
CHALLENGE: One Time Token: 145669
🔐 Enter Private Key Password: *********
which is clear since the authentication failed even before i could enter the OTP and a SIGUSR1 restarts the process. Seems that openvpn-authenticator have a problem somewhere here.
Also, the processes OpenVPN and openvpn-authenticator can not be stopped via WUI, need to kill them manually if i want to make changes in WUI otherwise i get an address in use error message!
the first answers from my side where also to go into a deeper understanding with this so may there is no solution according to your questions even the old tests with OTP (Google authenticator but also Oathtool) might give some more background information since both solutions worked for IPFire at that time.
thank you for your kind words and your welcome but i try to handle it the best i can to go beside the current IPFire state also if there are some “development” topics in here fromme, they might be (in early days they where much more) a chance for more helping/testing hands and eyes and also for potential background information and the search engine . But again thanks for the flowers.
Your welcome, even we found in here not a solution for a working 2FA may there are some ideas to go into a more detailed bug description/conversation?!
Spoken about my problem according to the disabled PFS, i found in the code that this is not my individual problem since the ‘reneg-sec 86400’ is hardcoded and can not be changed via WUI so the renegotiation of the data channel key happens for everybody (if you use 2FA or not) only every day instead of before and also the OpenVPN default every hour by the usage of a 64 bit block cipher even every 61 MB of data transfer which is also disabled if reneg-sec has been set fixed. In my opinion this is weakening of an important security aspect of the VPN! May (hopefully) this will find also into a discussion and to some changes.
As a beneath one, may we can collect in here some problems which appeared for the users in the different topics according to this 2FA development what do you mean @cfusco ?
Hi @ummeegge , i think you need to raise this in the dev mailing list or probably better raise a bug for this.
The core devs are so busy that they only occasionally read the posts in the forum.
Plus if it is a bug the wiki says a bug should be raised in Bugzilla and not on the forum or in the mailing list unless you are supplying a patch to fix something in which case it must be provided into the mailing list.
@ummeegge Hi Erik, I still need to go through your text with the appropriate focus, but for the next couple of weeks I will not have the time. However, when I find the time I will prepare a summary and file a bug report for the 2FA problem.
This is all I wanted, understanding the nature of the problem so I could give reliable information here in the forum. Thank you so much for providing the knowledge and skills that I was missing to get to the bottom of this issue.
About the PFS disabling problem, I agree with what @bonnietwin Adolf was saying, probably you could consider writing up the results of your research in a bug report to submit to developers. Having said that, as you suggested we could use this thread for lower-signal/higher-noise discussions and reporting among the users concerning these two problems, without bothering the bug report system?
Or maybe split in two threads, one dedicated to the SPF and the other the 2FA (changing the title as well)? Even without adding anything new, this thread is already valuable for the user of OpenVPN in IPFire.
I wonder what @jon thinks, as he is the expert in keeping the forum readable.
EDIT: I misspelled Erik name, which I corrected now. My apologies to @ummeegge
Remember that the OpenVPN 2FA was funded by a company who wanted the capability.
The end result worked for them.
It is obviously not working for all client systems. From discussions in an earlier dev conf call i know they would be happy to have bugs raised for these situations together with the logs or info showing where things are not working so that fixes can be implemented.
It is good @cfusco that you will be raising bugs for these as without a bug report the issues definitely won’t be fixed.
@jon Sorry, I meant PFS (Perfect Forward Security) which gets disabled by the hard coded reneg-sec 86400 setting (see post 10), as @ummeegge Erik has brought this issue as well.
Basically, I inquired about the 2FA not supported by most clients, Erik has helped clarifying the situation in that regard (post 7) but has also introduced a more important issue with the accidental disabling of this security feature (PFS). Now the two topics are intermingled here.
EDIT: Maybe I can change the title of this thread with a brief description of both problems?
have seen this by the conversation with cfusco and i think the forum is also a possibility, may one of the best, to find bugs and discuss them with people (with the IPFire community) in special to avoid bug deliveries cause of wrong configuration or misunderstanding of a feature. Also, if there might be a solution why not test them in the forum as we did it in the past many times ? This result might be also helpful for Bugzilla or the dev mailinglist and spare time for the developers since, as you already wrote, the time is less and if people can help why not ?
technically i am currently not sure how this should work on some client systems and on some not, may you know more about this ? Even the wiki lined clients for mostly OS´es and the support of 2FA out i used simply the terminal and got above mentioned messages which leads me to this question and answer conversation with cfusco also with a little hope that someone comes up and says “here it simply works try this and all is good” which was not the case until now.
Another one is, funding something which works only for some but for others not but lowering the security level for all disputes conclusion for myself!
Thanks again to @cfusco for bringing this to light otherwise i haven´t recognized this changes that fast.
. But again thanks for the flowers.