[eduVPN-deploy] Fixed IP - ccd

[François Kooman]

On 25.07.22 10:14, Frank Weis via eduVPN-deploy wrote:
> Hi,

Hi Frank!

Thanks for writing! I'll respond 'inline' below, sorry for the long mail!

> I might have a use case where this would really save my day:
> I want to deploy eduVPN to provide access to internal resources, and I would need a LOT of different profiles.
> I see several different ways to get there:

Did you consider grouping users together in a few different profiles? 
Perhaps it is not necessary to make the separation (very) strict?

If the applications themselves do not offer sufficient protection, i.e. 
weak authorization/authentication, then it might be needed to protect 
them with a VPN indeed and even block otherwise trusted users from even 
accessing the IP ranges of said services.

A possible approach is to create a profile _per service_ and only allow 
the users in that require access to that service. It might limit the 
number of profiles required?

> 1. fixed IP per client (the IP could be returned by SAML)

This is essentially the same as giving every user their own profile, but 
a bit annoying to manage from the VPN side. This is currently not 
possible in an automated way, it would require lots of configuration...

> 2. lots of different profiles (is there still a limit of 64 profiles in v3?)

There can be as many as you want in 3.x, note I didn't test it with more 
than ~10 profiles myself, but the restrictions that were there in 2.x 
are gone, so if it doesn't work with many many profiles it is a bug that 
will be fixed.

> 3. find the right place to place hooks in the connection/disconnection code, where I could call a script(username, vpn-ip) that opens/closes the firewall accordingly.

This would become 'nasty' in the sense that helper daemons need to be 
written to manage all this which increases attack surface. Ideally this 
should be avoided...

> 1. would be easiest to implement for me, and quickest for the user

This is possible, but lots of work to do manually.

> 2. doable, but it might not scale well if I had 250 profiles

It will work, but should really not be done. Also, if you do this, it 
makes a lot of sense to go with WireGuard and not OpenVPN. It will be 
much more efficient.

> 3. doable, but I'd be grateful for tips on where to place my connect/disconnect calls

As said, this is not a great solution...

So, what are exactly the problems implementing this *in the service* 
directly? I'll try to sum some of them up so we can talk about this. I 
also created an issue where I want to track this and will copy/paste 
some of the discussion there as well in the (near) future so we have 
everything together:

https://todo.sr.ht/~eduvpn/server/84

So let's dive in and I'll share some of the context on why this is 
currently hard to do... Please feel free to comment on any of this, in 
case you see something that I'm overlooking or make too complicated for 
no reason!

1. We built the VPN service primarily to be able to handle many users 
over a few different profiles and optimized configuration for this, i.e. 
we have static configuration files. This makes sense if you have 5 
profiles, but not if you have 500 profiles, then the configuration would 
have been organized differently...;
2. OpenVPN has (hard) limits on how many users it can handle per 
process, so we need to run many OpenVPN server processes to distribute 
the load over CPU cores;
3. We support "multi node" deployments for scalability reasons so 
multiple / many systems can be used to dynamically distribute the users 
over, so IP management becomes much more complicated;
4. The firewalling is done *statically* to make it more secure, reliable 
and easier to understand/update/modify for particular deployments.

So when you want to assign a particular IP address _per user_ or even 
_per device_ you are limited to "single node" deployments as well as 
single process (in case of OpenVPN). IP addresses MUST be unique over 
all the different nodes.

Furthermore, when using OpenVPN, with the current architecture you 
basically need to start a single OpenVPN server process per user, which 
is a bit of a waste. This is less so in the case of WireGuard obviously, 
there is doesn't really cost anything, assuming we don't run into any 
WireGuard limitations along the way.

So, we are a bit stuck between a rock and a hard place. If you run your 
own OpenVPN server on a single system with let's say around 100 users 
and you know all you users, it is easy to manage this manually and 
assign IPs to particular users. If you have 5000 users, this would 
become impossible and you need to somehow handle scaling issues that 
don't exist when dealing with 100 users.

The question is now: how to merge those two things? i.e. make it 
possible to configure what you need, i.e. IP per user/client and being 
able to scale up to 1000s of users without making things (too) 
complicated or brittle that it falls over easily. To me this is an open 
issue for which I currently have no clear answer.

If we start working on this, it makes sense to take all the above 
scenarios in consideration.

Hopefully you have some ideas that can get us moving :)

Thanks!

Regards,
François