AS test run issues

doomdog

Greetings,

At our company, I have been tasked with finding and deploying a (commercial, supported) VPN solution for around 100 users.
Previously, we used OpenVPN community edition, with a lot of customization and scripting.
After the required research, I have decided to give OpenVPN AS a go and these are my findings/problems which stop us from purchasing:

1. We have a policy that says: any VPN connection has a hard timeout of 8 hours, i.e. an authenticated client must not have a session
longer than 8 hours in any circumstance. After this period, a reauthentication must occur.
With the previous solution, I used a cron script to examine the status file (server config "status" option) and kill the "offending" connections.
With AS, I cannot use this, as status doesn't really work, so I've employed the vpn.server.session_expire parameter, which works, BUT only
for the Connect client - with e.g. OpenVPN GUI it stays connected (more exactly, it reconnects transparently and without asking for credentials).
Is there a way to enforce a maximum connection duration at the AS level, regardless of client version and/or configuration?

2.We also have a policy of maximum 2 simultaneous connections for any user. I now only have two options: 1 connection or unlimited.
I have thought of 2 ways to solve this:
a) Leave the simultaneous connections unchecked (1 conn per user) and give each person two installers; but I couldn't find a way to generate
and associate two different certificate/key pairs for each user.
b) Configure AS for simultaneous connections (I presume, basically, this adds --duplicate-cn to the server config) and use something similar to what I am doing
now with the FOSS openvpn (scripting around the client-connect hook); but I'm not sure this is feasible.

3.I would like to completely shut off the client web site, as we already generate and distribute the installers (profile included) by ourselves. But this
seems to break 2FA. Is there a way to have the included TOTP feature working without the API? Preferably using a concatenation of the one time code and the user password...

4. Lower priority: we have set a web session timeout of 10 hours ( "sa.session_expire": "36000") but the admin
interface still disconnects way earlier than that (after around an hour or less IIRC).

Our environment: OpenVPN AS 2.1.4 on Centos 7, authenticating against Active Directory LDAP.

Thank you.

The Johan

Hello little puppy,

> any VPN connection has a hard timeout of 8 hours

Okay, by default we use 24 hours, but you can change it to 8 hours if you like. This applies to standard accounts. If you give a user the autologin privilege, this timeout doesn't apply. For all other accounts; you have to reauthenticate after the specified amount of time. There are some caveats you need to consider;

- When a user authenticates, a session token is generated and used to identify this user from that point onwards. The default timeout of a session token is 5 minutes if there is no active connection. The default total validity of a session token is 24 hours. This can be changed to 8 hours.
- The session token is presented and used when connecting, reconnecting after an interruption, and refreshing a TLS encryption key. A valid TLS key is required for continued connectivity. The refresh moment is one of the moments when the session token is checked for validity. It should coincidence with the end of the validity of the session token to ensure the connection doesn't last longer than you expect.
- With the default settings of 24 hours for the token and 6 hours for the TLS renegotiation, a connection can last only 24 hours. There will be a TLS refresh at hour 6, hour 12, hour 18, but not at hour 24 because then the session token is expired at the same time that the TLS key expires. Without valid TLS key, the connection ends.
- The default refresh of a TLS key is 6 hours. If left unchanged and your session token timeout is set to 8 hours, TLS refresh happens at hour 6. The TLS key is then valid until hour 12. The connection can then last a total of 12 hours, unless an interruption occurs in the connection and the session token is then checked between hour 8 and hour 12, which then results in a disconnect.
- If you use session validity of 8 hours, set the TLS refresh to for example 1 hour, 2 hours, or 4 hours, or 8 hours. The refresh then coincides with the 8 hour mark and the connection will end at the expected time then.

See documentation here:
https://docs.openvpn.net/docs/access-server/openvpn-access-server-command-line-tools.html#session-management

If you specifically instruct the client software to store/remember the username and password and to automatically reconnect and start a new session with these credentials, that's a configuration problem on your client side that cannot be solved from the server end. From the server end, it will be seen as a perfectly normal session that lasts 8 hours, and is then ended as it should. If the client is then configured to automatically use stored credentials (not secure) to start a new session again, then that will be seen as the same thing as the user entering his or her credentials again to start a new session. This is a problem purely on the client side and if someone is configuring things this way, then there's not a hell of a lot you can do about it. This would imply a custom configuration on the client side that is, as far as I know, not the default.

> 2.We also have a policy of maximum 2 simultaneous connections for any user. I now only have two options: 1 connection or unlimited.

Sorry, Access Server only supports either 1 or unlimited. You can't set a custom limit.

> a) Leave the simultaneous connections unchecked (1 conn per user) and give each person two installers; but I couldn't find a way to generate
and associate two different certificate/key pairs for each user.

Yes, that's a solution: create 2 accounts for each person. Each user account is given its own private key/public key pair automatically. No two user accounts on the Access Server will have the same private key/public key pair.

> b) Configure AS for simultaneous connections (I presume, basically, this adds --duplicate-cn to the server config) and use something similar to what I am doing now with the FOSS openvpn (scripting around the client-connect hook); but I'm not sure this is feasible.

Yes I believe underwater it does add that parameter to the server config. You can't use the client-connect hook on Access Server, unfortunately. What you can do is add a post_auth hook to Access Server. This is a piece of Python programming that you can load into Access Server that runs after a successful authentication. With it you can provide additional conditions. You could for example ask an extra question of the user through the OpenVPN Connect Client, like for multi-factor authentication. Or you can look at their reported MAC address of their computer and allow access only to whitelisted system. Or, what you can do, is read the output of the command /usr/local/openvpn_as/scripts/sacli VPNStatus and count how many times this user is already connected. If it's 2 times or more, you can then tell the Access Server to deny this user access, with some error message that is shown on the client side like "too many connections" or whatever.

See documentation here:
https://docs.openvpn.net/docs/access-server/openvpn-access-server-post-auth-scripting.html

> 3.I would like to completely shut off the client web site, as we already generate and distribute the installers (profile included) by ourselves. But this
seems to break 2FA. Is there a way to have the included TOTP feature working without the API? Preferably using a concatenation of the one time code and the user password...

I think you need to check again how you are generating these installers because I just tested and it doesn't break 2FA.

In any case I would advise against this. The client web UI is perfectly fine to have open to the Internet. It's got security lockouts against bruteforcing, and it's a custom implementation of Twisted Web that is pretty damn hard to break. As long as you set it with TLS 1.2 and put a secure cipher suite in place, and you use decent passwords, you'll be fine. But the choice is yours I guess so here goes...

You're going to make life very difficult for yourself if you're going to get rid of the client web UI entirely. For one, you want to use the built-in multifactor authentication, right? But enrollment for that happens through the client web UI. How are you gonna solve that? You'll have to manually input google authenticator codes into the configuration database, and manually pass this code to the user. Additionally you'll have to manually generate all the client installers, one for each user account.

This is going to be a hell of a pain but if you REALLY MUST do this then okay. Up to you. Not my advice anyways.

Normally the Connect Client is given to a user and they run it. When they enter credentials this is checked with the Access Server over a secure channel, through the web services. Disabling this means this doesn't work. That means you have to manually provide the user with either an installer bundled with a user-locked profile or manually have the user import a separate user-locked profile after installing an 'empty' Connect Client installation.

Google Authenticator is normally also checked through the web services. But if you manually provide a user-locked profile, this can be done without the web services as it will then go through the VPN tunnel during the authentication phase directly. You will notice that this is the case because the login screen on the Connect Client will ask you for username, password, and Google Authenticator code, in 1 authentication screen, not in 2 separate steps.

Here are some documentation pages you'll need to manually take care of everything;
https://docs.openvpn.net/docs/access-server/openvpn-access-server-command-line-tools.html#profile-installer-generation
https://docs.openvpn.net/docs/access-server/openvpn-access-server-command-line-tools.html#google-authenticator-faq

If you have the following conditions met, it will work:
- Client web services are unreachable for the client
- Requirement for Google Authenticator is enabled
- The Google Authenticator shared key is set and locked for this user account in the user database on the server side
- This shared key is given to the user and configured in their Google Authenticator app of choice
- You generate an installer for this user of type msi or dmg with a bundled standard user-locked profile
- This installer is then placed on the computer of the user, and installed there

Then it will work. I've just tested this to be 100% sure.

> 4. Lower priority: we have set a web session timeout of 10 hours ( "sa.session_expire": "36000") but the admin interface still disconnects way earlier than that (after around an hour or less IIRC).

Not sure, would take too long for me to check but I can well imagine that you have set this parameter but have forgotten to implement it by either restarting the Access Server service or using ./sacli start in the /usr/local/openvpn_as/scripts/ folder to have this value loaded and implemented. But really, 10 hours? You're concerned about the client web UI but you want the admin web UI to be left open for 10 hours? Okay then.

I hope the above helped you. Good luck.

doomdog

Hello little white star and thank you for the quick answer.

> any VPN connection has a hard timeout of 8 hours

If you specifically instruct the client software to store/remember the username and password and to automatically reconnect and start a new session with these credentials, that's a configuration problem on your client side that cannot be solved from the server end. From the server end, it will be seen as a perfectly normal session that lasts 8 hours, and is then ended as it should. If the client is then configured to automatically use stored credentials (not secure) to start a new session again, then that will be seen as the same thing as the user entering his or her credentials again to start a new session. This is a problem purely on the client side and if someone is configuring things this way, then there's not a hell of a lot you can do about it. This would imply a custom configuration on the client side that is, as far as I know, not the default.

I fully agree. I am not trying to achieve the impossible (controlling the user's actions) but what I am observing is not really falling within this case.
I have an older (2.2.2) OpenVPN GUI which is simply running the (unmodified) .ovpn downloaded from the AS (i.e. no caching of username/password I presume). The same .ovpn works in Connect (i.e. the session is disconnected and I am asked for credentials). I have set the TLS reneg at 5 min and the session age at 10 min. If I use the Connect client there are mentions of the session token in the log. With the old GUI there is nothing about it in the AS (or client) logs, only the normal TLS soft resets every 5 mins and "2017-03-25 17:42:39+0200 [-] OVPN 4 OUT: "Sat Mar 25 15:42:39 2017 MANAGEMENT: CMD 'client-auth-nt 3 24'", where the 24 increments itself.
What I mean is that even if somehow the client would reauthenticate itself without interacting with the user, I should at least see something _other_ than the normal TLS refreshes once every 10 mins. Maybe something escapes me at this time.
Perhaps a solution is scripting around sacli vpnstatus and killing users (virtually 😉 ).
Moreover, I think that enforcing 2FA could take care of any too-smart-for-his-own-good client, by at least requiring something not known in advance (technically, the OTP can be calculated for an arbitrary moment, but this gets too deep for even the most stubborn users).
This gets me into the whole reasoning behind requiring OTP when the certificate is already "something you have", but this is a whole other discussion...

> 2.We also have a policy of maximum 2 simultaneous connections for any user. I now only have two options: 1 connection or unlimited.

Sorry, Access Server only supports either 1 or unlimited. You can't set a custom limit.

Yes, fully understood but not fully accepted 🙂

> a) Leave the simultaneous connections unchecked (1 conn per user) and give each person two installers; but I couldn't find a way to generate
and associate two different certificate/key pairs for each user.

Yes, that's a solution: create 2 accounts for each person. Each user account is given its own private key/public key pair automatically. No two user accounts on the Access Server will have the same private key/public key pair.

This would mean having two accounts in Active Directory for each person, which is not going to happen.
I know that the CN on the certificate is tied (internally in AS) to the username from AD (or RADIUS, or PAM, or local). I was hoping to find a way to create two certificates, with different CNs, but associated to the same username.

> b) Configure AS for simultaneous connections (I presume, basically, this adds --duplicate-cn to the server config) and use something similar to what I am doing now with the FOSS openvpn (scripting around the client-connect hook); but I'm not sure this is feasible.
[...] Or, what you can do, is read the output of the command /usr/local/openvpn_as/scripts/sacli VPNStatus and count how many times this user is already connected. If it's 2 times or more, you can then tell the Access Server to deny this user access, with some error message that is shown on the client side like "too many connections" or whatever.

Yes, this is very similar to what we are doing now . I might have to get aquainted with the post-auth python thing and some xml parsing...
A good script could prove to be a solid solution to globally set the simult. connections to 2 or whatever number, but I kinda expected this work to be done already inside AS 😉

> 3.I would like to completely shut off the client web site, as we already generate and distribute the installers (profile included) by ourselves. But this
seems to break 2FA. Is there a way to have the included TOTP feature working without the API? Preferably using a concatenation of the one time code and the user password...

I think you need to check again how you are generating these installers because I just tested and it doesn't break 2FA.

I have based my assumption on something others are saying, not completely fair, I know.
I need to test this and get back to you. I am generating installers with sacli, nothing special.

In any case I would advise against this. The client web UI is perfectly fine to have open to the Internet. It's got security lockouts against bruteforcing, and it's a custom implementation of Twisted Web that is pretty damn hard to break. As long as you set it with TLS 1.2 and put a secure cipher suite in place, and you use decent passwords, you'll be fine. But the choice is yours I guess so here goes...

Ok, this sounds reassuring, I will consider leaving the client web up.

You're going to make life very difficult for yourself if you're going to get rid of the client web UI entirely. For one, you want to use the built-in multifactor authentication, right? But enrollment for that happens through the client web UI. How are you gonna solve that? You'll have to manually input google authenticator codes into the configuration database, and manually pass this code to the user. Additionally you'll have to manually generate all the client installers, one for each user account.

We are used to doing things that way, but I wouldn't refuse an easier path...

Normally the Connect Client is given to a user and they run it. When they enter credentials this is checked with the Access Server over a secure channel, through the web services. Disabling this means this doesn't work.

Yes, I've read the documentation, I know the profile (.ovpn file) is downloaded from the AS, and I feel a bit uneasy about having access to the certificate (a potential second factor in itself and an actual private key as well) based only on credentials (coupled maybe with the OTP).

Google Authenticator is normally also checked through the web services. But if you manually provide a user-locked profile, this can be done without the web services as it will then go through the VPN tunnel during the authentication phase directly. You will notice that this is the case because the login screen on the Connect Client will ask you for username, password, and Google Authenticator code, in 1 authentication screen, not in 2 separate steps.

This I didn't know, as I haven't reached the GA testing phase yet because the session age issue is blocking.
Hmm, if I enforce 2FA, might this even eliminate older clients altogether, by rendering them uncapable of performing the auth?
(And thus, forcing users to install the package provided by us, and not simply throwing the .ovpn into any openvpn compatible client software. Taking care of point 1. at the same time).
BTW, do you happen to know of an OTP app which stores the secret safely in the phone (i.e. not so easily accessible as in Google's own app, for which it is trivially recoverable on a rooted device)?
We are not really ready to buy 100 Yubikeys 😉

If you have the following conditions met, it will work:
- Client web services are unreachable for the client
- Requirement for Google Authenticator is enabled
- The Google Authenticator shared key is set and locked for this user account in the user database on the server side
- This shared key is given to the user and configured in their Google Authenticator app of choice
- You generate an installer for this user of type msi or dmg with a bundled standard user-locked profile
- This installer is then placed on the computer of the user, and installed there

Then it will work. I've just tested this to be 100% sure.

This is almost step for step the on-boarding workflow I imagined myself.

> 4. Lower priority: we have set a web session timeout of 10 hours ( "sa.session_expire": "36000") but the admin interface still disconnects way earlier than that (after around an hour or less IIRC).

Not sure, would take too long for me to check but I can well imagine that you have set this parameter but have forgotten to implement it by either restarting the Access Server service or using ./sacli start in the /usr/local/openvpn_as/scripts/ folder to have this value loaded and
implemented.

Oh, of course I did sacli start. In fact, at each modification of the config I always bounce the openvpnas service as well, this is a testing playground for now.
I will try to find the exact duration of the admin web session and maybe find this number somewhere. In any case, it really doesn't honor the parameter's value I've set. If it matters, I always logon at the admin web with the bootstrap user.

But really, 10 hours? You're concerned about the client web UI but you want the admin web UI to be left open for 10 hours? Okay then.

This is for my own comfort, while I am changing and testing stuff. If this goes to production, it will be set to 10 mins (it it works!) =)

I hope the above helped you. Good luck.

Definitely helped, thanks.