[eduVPN-deploy] Fixed IP - ccd

Mon Jul 25 15:40:14 CEST 2022

Hi François,

thanks a lot for taking the time to explain all this.

Some of the things, especially regarding fixed IPs in a multi-node-setup hadn't occurred to me as hadn't looked at this for the moment.

I'll try to provide some context, as it will probably help to understand where we are headed.

We have two types of VPN users:

  *   'our own': they have a secure-deployed device, with client certs issued/renewed automatically. The devices open an IPSec (road warrior) Tunnel as soon as they can, without user interaction. When the user wants access to internal resources, he accesses (though the tunnel) an internal web server. A (2FA)-Login on the web server triggers the 'open firewall' script. The resources that the user is allowed to access are in the SAML response. The firewall closes when the web page stops being refreshed. We have used 'nativefier' to encapsulate this login/refresh into a standalone app.
  *   external users: we have no control over their devices, and they can access less critical resources. They could be teachers, students, external  teachers, suppliers. This population would use eduVPN. Our idea was to distribute short-lived sessions (max 12hrs) so the need to auth (with 2FA) against our SAML more or less each time they connect. This would bring us 'close' to having a multi-client-platform,very user-friendly 2FA VPN solution.

Reading your explanations, I think fixed IPs is probably not the best idea, so we are back in a scenario where something needs to happen when the tuple (username, clientIP) is known. Either automatically (the nasty way) by having eduVPN call a custom connect/disconnect script, or, by having trigger something like we do with 'our own' users. We would very much prefer to avoid the latter, as forcing the user to perform two different steps is a lot harder to communicate and support.

Thanks a lot for your input!

Regards, Frank

On 25.07.22 12:53, François Kooman wrote:

ⓘ This message was sent from external user !
Please do not click links or open attachments unless you recognise the source of this email and know the content is safe.

________________________________

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
--

Frank Weis
Conseiller informaticien

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Ministère de l’Éducation nationale, de l’Enfance et de la Jeunesse
Centre de gestion informatique de l’éducation

eduPôle - Walferdange
Route de Diekirch, L-7220 Walferdange
Adresse postale : B.P. 98, L-7201 Bereldange

Tél. Helpdesk: (+352) 247-85999 . Tél. Secrétariat: (+352) 247-85970 .Fax : (+352) 247-85174
E-mail : Frank.Weis at cgie.lu<mailto:Frank.Weis at cgie.lu>
www.cgie.lu<http://www.cgie.lu/>
www.men.lu<http://www.men.lu/>
www.gouvernement.lu<http://www.gouvernement.lu>
[cid:part1.3Ov7tbzB.ojTQqorn at cgie.lu]
Ce message et toutes pièces jointes sont établis à l'intention exclusive de ses destinataires. Ils peuvent contenir des informations confidentielles. Si vous recevez ce message par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. Ce message a fait l'objet d'un traitement anti-virus.

Le contenu de ce message et des pièces jointes ne pourrait engager la responsabilité du ministère que s'il a été émis par une personne dûment habilitée agissant dans le strict cadre des fonctions auxquelles elle est employée et à des fins non étrangères à ses attributions.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://list.surfnet.nl/pipermail/eduvpn-deploy/attachments/20220725/3fd06dae/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: YYnewdssgPzAXTBg.png
Type: image/png
Size: 48587 bytes
Desc: YYnewdssgPzAXTBg.png
URL: <https://list.surfnet.nl/pipermail/eduvpn-deploy/attachments/20220725/3fd06dae/attachment-0001.png>