[Worked Around] Limiting which users can connect to an OpenVPN Instance?
-
So use LDAP instead?
-
Thanks for the suggestion, but I'm not sure how that would help the situation.
I could at least set one instance to "Local Database" and one to "LDAP", but then I'm screwed if I ever need a 3rd instance, and I have to setup an LDAP server.
Changing the authentication method does not really add any granularity to each server instance.
I may be able to bring up a new internal cert authority, since the cert authority is assigned per-instance of OpenVPN server… so if a user had no cert in the authority tied to the instance, they would not be allowed to connect.
-
What do you mean here really? How does using user groups properly per VPN server instance NOT add granularity? Add LDAP instance for each VPN in the pfSense GUI, set up groups as needed.
-
Maybe I misunderstood your initial response.
I'll try to clarify:
Using the internal database and using LDAP should both provide access to the concept of groups.
I guess what I'm missing is where I can integrate the groups into the OpenVPN server setup for each instance. I just don't see the option to say "Group X is allowed to log onto this VPN Server instance". Is it there and I missed it? How do you properly use groups per VPN Server?
-
You set up multiple LDAP servers in System: Authentication Servers. All is done there. You assign those as needed to your VPN instances. Done. Perhaps, start here?
https://doc.pfsense.org/index.php/OpenVPN_with_RADIUS_via_Active_Directory
-
Okay, I see how that could work. That implies I have an LDAP server handy, which I do, but I currently manage VPN passwords in pfSense rather than from our normal LDAP accessible accounts (AD).
It seems like there should be a way to do this with the groups in the internal user db.
Thanks for the suggestion though. That will work if I can't work out a better way.
-
Okay, this is the best I could come up with for those who find this thread:
Since each OpenVPN instance can specify a different certificate authority, I just created a second CA for these special users.
That way, if they try to hop on the other instance by changing the port, even though the username/password is correct, they will fail the TLS handshake and not gain access.
It is a workaround, but I think it is the best I can get without playing games with LDAP.
On my wishlist would be: "Groups allowed to log in to this OpenVPN Server" setting, and maybe the ability to add a second local user database in pfSense like you can multiple LDAP entries.
-
Wouldn't exactly call it a "workaround".
If you've gone to the trouble creating a separate OpenVPN Server instance, it makes sense to use a unique certificate chain (new CA, server cert, etc).That way there's no way to cross over between the server/subnet/access settings unless you explicitly set it up.
You can still allow for a unique "special" customer that gets some/all company access via the CSC entries.Perhaps just my bent, but that's the direction I would have chosen from the start to keep things separate yet give you flexibility.
Just my $.02
-
Wouldn't exactly call it a "workaround"…
I called it a workaround to my problem which is a lack of user auth granularity (with respect to openVPN). In the end, it really is a better way to do it, I just wish I could manage users and groups "per vpn" with a bit more precision.
Thanks to the work put into pfSense, bringing up a new VPN instance is super easy and fast… I just had to realize that when I did that a new CA and such was appropriate to keep the single pool of users separate. I'm getting a better handle on all this now.
I still don't really like that a user can change their port and be authenticated to the point of the TLS handshake failing, but that is good enough for my needs. I know I can fix that problem with adding multiple LDAP connections, I just wish I could instantiate a new local user DB, or even just a group and apply them with allow/deny rules to the openVPN instances separately.
Your 2 cents are appreciated, it is an answer to the question, I just had to get it figured out on my own.
-
If you expect granularity for certificate-based authentication, it needs to be done based on certificate attributes, not groups.
A "new local user DB" just doesn't make sense. That's not how it works anywhere. You cannot have multiple local user DBs on Windows either, just doesn't work that way - the user either exists or not. If you need more complex stuff, you really need LDAP. -
I still don't really like that a user can change their port and be authenticated to the point of the TLS handshake failing
I would argue that they're attempting to authenticate if they change their assigned port. If they don't have a cerftificate that matches the required chain, they simply get refused. From my POV this is no different than a badguy/hacker/whathaveyou trying to break in once they've figured you have a port open in your firewall for OpenVPN. In the real world it's going to happen and is to be expected. It's also part of the reason I like SSL/TLS authentication, it works (so far so good).
Your 2 cents are appreciated, it is an answer to the question, I just had to get it figured out on my own.
In the end that's what I find works best (for me anyway). Once you've picked a solution that works for you and you can wrap your head around it, then it's "real" and becomes second nature.
I find reading these forums for other people's problem and other's solutions is an excellent way to get a new POV on how this all works (or doesn't).
Glad you're up and running, keep at it and keep learning :D
-
I think the bottom line is that for some use cases we need to be able to manage groups at the VPN server level.
The preferred solution is to use LDAP but LDAP is not a accessible for everyone. Having a LDAP to manage VPN permission is for a lot of us overkill. It adds complexity, cost, single point of failure etc …
A simple workaround would be to install (package) a local LDAP instance on as a Local LDAP. Ideally this would be sync with the backup instance as well.