OpenVPN curious login behaviour

[gdur]

I've defined a couple of users to give VPN access authorized by OpenLDAP. Exported the various .ovpn config files.
Now I noticed that I'm able to login using User A's config and using User B's credentials(). Is that a bug?

[fabian]

Usually not. The config should be the same for all users except if you have some special overrides.

[casper1980]

Did you create separate user certificates for each client?

[gdur]

Hi Casper1980,
Yes I did. As stated: "Exported the various .ovpn config files."
The configs look familiar to me all with their personal certs. That why I believe there's something wrong...

[gdur]

I've investigated this behavior even more:
I've compared the various *.ovpn configs once more and these are definitely user specific with their own cert and private key. As stated before I am able to login using another user's credentials. It's even worse, I also am able to login using another LDAP defined user which isn't imported into OPNsense(!!!).

Another thing observed is that after importing a LDAP user into OPNsense (System -> Access -> Users) this user was right away available to export (VPN -> OpenVPN -> Client Export) without being defined in VPN -> OpenVPN -> Clients. This requires an explanation as to why. This is something I wouldn't expect.

Going even further I found out that the login issue might be an OpenVPN issue as I tried the same on my OpenBSD box (I'm currently in the process to move from OpenBSD pf to OPNsense) having OpenVPN installed as well. And guess what, the same weird login behavior. Didn't noticed this before but it seems that this is rather an OpenVPN issue. But nevertheless the other stuff remains...

@dev-team: Any ideas? I'm more than happy to demonstrate these findings.
 

[bartjsmit]

OpenVPN uses 2FA - the first factor is the certificate which is matched as being issued by the same PKI as the server's cert. You can also use a shared secret without PKI (OpenVPN static key). The second factor is successful authentication to whichever back-end you use (local, RADIUS, LDAP, etc.).

These factors are independent, which is why you can match the cert for one user and provide credentials for another. This lets you disable a lost client device by revoking the certificate, and lock out a user by disabling their account.

If you want to separate your users into groups, you need to run separate OpenVPN servers. Normal practice is to have a different UDP port number for each. This also lets you specify different firewall policies, since their tunnel IP subnets will need to be different. You have 64K ports to choose from, so go to town ;-)

Bart...

[casper1980]

Can you set the "Enforce local group" under VPN -> OpenVPN -> Servers -> [server]  Settings? 

If so then create a group .. say 'vpnusers' and add your vpn users to this group and specif that group inthe above. This should ensure that only users who are a member of a specific group can connect via VPN..

NOTE - This will only work for servers using Local Database for Authentication (with TOTP as well) as far as i know although i have not fully tested this so see if radius users could be similarly restricted.

This should at least prevent users who are not 'vpn users' - who can have their own group from connecting...

One thing that might help in understanding this problem is the distinction between 'client' and 'user'.  The Client certificate that is specified in the VPN 'Client Config' is actually called a user certificate which is probably where some of the confusion starts.  I also note that despite the "User Authentication Settings" section of the Clients config you can authenticate with any valid user subject to the group membership enforcement (see above) which is a little distracting but I think this may be used when you disable user auth on the server.. which may be a way round this but will need testing.

So.. the client config specifies the client  (machine / endpoint) that is authorized to connect to your vpn... only endpoints with the certificate can even attempt to connect successfully. Then you have an added layer of 'users' who can connect.. and these can be restricted to a specific group. I don't think there is a way to prevent a legal user from connecting via another users client through any standard means...  However there are some resources around that suggest you can TAG connections with the username so as to create a specific set of firewall rules etc on a per user basis if you so wish...  https://forum.netgate.com/topic/111272/limit-openvpn-access-for-certain-user-to-only-certain-ip-in-the-local-network may also provide a way round this:

I think that's 'just how it works'.. no bug as far as I can tell here.  I hope this makes sense.

[gdur]

Hi Casper1980, Thanks for your lengthy answer and suggestions however, it's not that I'm looking for a workaround because that's something I'm able to work out I guess.
The fact that the one Client can use another Client's credentials to get access is what's worrying. That's not the level of security one may expect. As I mentioned before this actually is a OpenVPN problem as far I can see as I found the same behavior with OVPN on my OpenBSD pf firewall. I will report these findings to OpenVPN.

I've investigated once more, to ensure I'm not making a mistake here, the various *.ovpn config files and these contain correctly the client specific cert and key.
As also explained I'm using OpenLDAP as a backend with OPNsense while using the local database on OpenBSD.

What I sense is that first the certificates, as exposed in the *.ovpn config file, are being validated and hereafter the Username and Password without considering to whom the cert belongs. My guess is that this likely is due to the authorization routine as provided by OpenVPN.
My other finding however, regarding accepting "Clients" who are NOT imported from LDAP worries me more, as this looks like being an OPNsense issue. Your suggestion of creating a specific group in OPNsense doesn't make sense as this is something what should be done in LDAP and using the proper "Extended Query" filter to only make VPN clients available to OPNsense, as per usual.
This is a bit related to my other post https://forum.opnsense.org/index.php?topic=14149.0 where I can't find a way to make OPNsense use the mail attribute only rather than the usual uid attribute. Both an e-mail address (mail) and a Username (uid) is being resolved positively which shouldn't be the case.

[franco]

It's doing two successive auth passes, not one joined auth pass with two factors.

The trouble is you create certificates under one CA which is *always* trusted implicitly . The individual certificates  are for identification (overrides), revocation (denying access) and expiration (key rotation). If you want identification to be a forward hint for the user credentials to be accepted effort needs to be put into the system at hand, not just the expectation that your security "standard" is just so.

I supposed you can create an individual CA and server for each user if you want the extra security to avoid implementing a feature like this and think about how to present it and how to deliver support for people trying to set it up expecting the opposite.


Cheers,
Franco

[iam]

@OP Have you activated the option "Strict User/CN Matching"?

[gdur]

Hi iam,

That partly solves the problem however, in this case I'm not able to use the mail address as a Username.
If it were possible to get the email address instead of the uid while importing the users from LDAP the problem would be solved as in this case the login procedure does not accept different user/Client credentials.
Just for my understanding, is  "Strict User/CN Matching" part of the OpenVPN server site config? Any idea where I can find this config?

[iam]

I think so:

Code: [Select]

username-as-common-name

The config should be in a file like /var/etc/openvpn/server1.conf