OpenVPN security

One thing I find frustrating is how thin the Untangle documentation is. It has served me well for learning the basics about pretty much anything, but if a person needs to know a bit more, how things work "under the hood", there seems to be no way find out more.
Writing to them usually produces a one-line reply after a couple days - at that rate, trying find out something useful takes too long.

As a result, most of the issues I have struggled with have not been with the product so much as my inability to source the information I need to set it up properly. I read postings (mostly replies to postings) from UT users here that obviously know the product more deeply than I ever will. Where do you dig up the detailed dirt on the product?

Anyway, this wasn't intended to be a rant, as I'm a big UT fan.

I am trying to learn how the security works with the UT OpenVPN service app. I see comments in the sales literature that claim Two Factor Authentication is now available in UT OpenVPN, but I can't find anything in the UT interface that offers this.

Further, I would like to be able to explain to my more security-conscious clients how the security works. Can I use a config file from any OpenVPN server to get into my server, providing I have a valid username and password? If not, exactly how easy/difficult would it be to counterfeit a config file to get in?

By explaining to a client that a person needs not only a working username and password, but also a config file that can't be counterfeited, it could almost be argued that 2FA is built-in.

Are the config files user-specific? Exporting a config file in the OpenVPN interface appears to be a user-specific thing. So, does that mean that if I use the config file for John Smith, would I need John Smith's credentials to use it?

Anyway, if anyone has seen a decent description on how all this works, I'd appreciate a link.

If Untangle sales told you that OpenVPN has 2FA... they need reeducated because it really doesn't.

That being said, depending on your configuration and the network you're defending it could be considered as close enough to 2FA to be 2FA. But technically speaking, it does NOT support 2FA. To say you support it, you must require two tokens in the same authentication event.

So... onward to addressing the rest.

If you take a peek at your OpenVPN settings, under the server tab, there's a check box there for Username/Password Authentication. Once enabled you have a choice of local directory, RADIUS, Active Directory, or Any Directory Connector. The latter 3 are only there if you have the directory connector premium module.

What isn't so obvious, is that VPN users are STILL authenticated via their certificates. The Username / password authentication is in addition to, but again isn't performed at the same time as the certificate auth. So it's very close to being 2FA, but it isn't technically 2FA.

Now, those certificates generated for each VPN client, these certificates do NOT AUTHENTICATE USERS! They authenticate MACHINES.

So, a connection is made with a valid certificate, then the username / password is requested. ANY USER authorized can authenticate there. There is NO MECHANISM to enforce a specific user to a specific VPN client (certificate) at this level. This is why it's NOT 2FA.

Using directory connector to attach Untangle to Active Directory to me is a waste of time. Domain resources will require an AD authentication to access them anyway. So what am I doing by making users login one more time on the VPN? But, it does enforce AD login before the actual network connection happens, which also means Untangle knows what AD user it is... and you can use that information to set policy. So it has policy value, but no real security value.

So yes, the documentation is a little thin. But at the same time I'm not sure how it could be improved. This stuff isn't really Untangle, it's how OpenVPN works. OpenVPN has its own documentation. But when you start combining things from everywhere as Untangle does, you wind up... well... tangled.

But, if you have an AD environment, and you use local directory with OpenVPN on Untangle. You create a situation where the user needs a certificate, a VPN login, AND an AD login to get into any AD protected resource. That's a TON of barrier, and a series of things I've never seen breached. But even if you do that, it's STILL not 2FA, just a stacked series of single factors. Is it good enough? It has been for me!

Wow, what a well-written reply!

Thanks for clarifying. Some of this stuff isn't as complicated as it seems, once someone sorts out the relevant bits.

Here's the page claiming that Untangle has 2FA in their OpenVPN offering: https://www.untangle.com/shop/openvpn/

Anyway, I bet this security is good enough too, and can now make the argument.

Thanks!

Quote:

---

Originally Posted by sky-knight

So it's very close to being 2FA, but it isn't technically 2FA.

Now, those certificates generated for each VPN client, these certificates do NOT AUTHENTICATE USERS! They authenticate MACHINES.

So, a connection is made with a valid certificate, then the username / password is requested. ANY USER authorized can authenticate there. There is NO MECHANISM to enforce a specific user to a specific VPN client (certificate) at this level. This is why it's NOT 2FA.

---

The post is a valid description, and well stated.

But it is also splitting hairs, based on my understanding.

So IMHO, it does not prove that it is "NOT 2FA".

Let's take a 2FA definition ==

1. something you know
2. something you have.

As far as OpenVPN, NGFW requires the 'have' part first, and you have to take extra effort to add the 'know'/password. This is the reverse order from common consumer experience.

It seems that 'what you have' is going to be a machine - whether it is an authenticator app on a specific smartphone, an USB key, or a certificate on a specific computer.

And the cert is probably stronger than a 'having' a code from an E-mail. And clearly more secure than a SMS text message, where you don't have to have a specific machine.

So I can't fault UT marketing at all. I don't think re-education is necessary.

The catch lies in the authentication events. OpenVPN doesn't use the two factors in the same authentication event, it runs them in series. As a result, the two authentication tokens are not actually attached to the same account. That means it's a series of factors, not multi-factor authentication.

A security company should know this, because that latter distinction MATTERS for high security environments. But it doesn't matter for many others.

As I indicated in my post, you authenticate the certificate, and then ANY user. To be 2FA, it needs to authenticate ONE user.

I do understand how many would assume that's splitting hairs, but it isn't. That's how MFA must work.