Amebis / eduVPN

Windows eduVPN Client
GNU General Public License v3.0
41 stars 16 forks source link

VPN pre-login possible? #195

Open Lukas-UAUX opened 2 years ago

Lukas-UAUX commented 2 years ago

Would it be possible to get eduVPN to connect pre login (Windows)?

Maybe similar to the way that Cisco AnyConnect (SBL) provides? If this module is installed, you get an additional icon next to the regular network-icon at the login screen. If you click on it the vpn app shows up, and you can connect to your network.

This would be a really nice feature, for example to have an active connection to the ActiveDirectory at login, for example for a new user or if the mobile account expired - and GPO of course...

rozmansi commented 2 years ago

I'm afraid this is not possible with the classic Windows VPN clients. However, your feature suggestion makes sense and I will investigate possibilities. See if there is a chance to implement it.

Lukas-UAUX commented 2 years ago

I have a very, very faint memory, that Cisco AnyConnect does it via a "login provider" (or is it credential provider?) Maybe that would be the trick

efef commented 2 years ago

We are actually working on pre-provisioning. The work done so far is documented here: https://github.com/FlorisHendriks98/eduVPN-provisioning In this page we describe how to leverage MS AD (and PKI) to do pre-provisioning. However at the moment we are working on another path: use MS intune in combination with an new eduVPN server API call to pre-provisioning Windows and macOS devices.

If you like to be involved @Lukas-UAUX please email us: eduvpn-support@lists.geant.org

Lukas-UAUX commented 2 years ago

That sadly doesn't look like it would fit our use case or environment. For one thing the user must be able to control the vpn and we have multiple networks/profiles that can not be tied to a machine identity but user only. Additionally eduroam which is considerably important at a university is a user-config network that starts after login - which would result in a lot of errors

ghost commented 2 years ago

Just to clarify, are you talking about "managed devices", or "bring your own" devices? We only consider "managed devices" as it seems (too) invasive to require users to subject their personal devices to this kind of control by their organization.

For one thing the user must be able to control the vpn and we have multiple networks/profiles that can not be tied to a machine identity but user only.

The way we saw this working is to take a "layered" approach. For example, the "system VPN" can only reach the AD server(s). A "user VPN", i.e. the eduVPN client. can later be used to choose a specific profile for a user and have additional MFA if so desired.

Additionally eduroam which is considerably important at a university is a user-config network that starts after login - which would result in a lot of errors

But how can you reach your AD server when there is no network connectivity at all? Having a VPN client available before login can't do anything if there's no network?

Lukas-UAUX commented 2 years ago

Of course managed devices, students and private devices of staff would have no use for pre-login.

The way we saw this working is to take a "layered" approach. For example, the "system VPN" can only reach the AD server(s). A "user VPN", i.e. the eduVPN client. can later be used to choose a specific profile for a user and have additional MFA if so desired.

Ouch that would kill VPN for any connection below 16 Mbits, to accommodate that much headers either fragmentation would kill it (TCP only, UDP would just stop working) or the MSS/MTU would be to low for any reasonable performance.

But how can you reach your AD server when there is no network connectivity at all?

They don't - the devices use a wired connection most of the time. A connection is only necessary when we change GPOs that require to be pulled on login or a new user logs in.

The pre-login is intended for HomeOffice or "emergency" scenarios, where the user has no possibility to use a wired connection at least sometimes.

ghost commented 2 years ago

Ouch that would kill VPN for any connection below 16 Mbits, to accommodate that much headers either fragmentation would kill it (TCP only, UDP would just stop working) or the MSS/MTU would be to low for any reasonable performance.

Do you mean this occurs when you run one VPN over another VPN? That was not exactly what I meant. With the "system VPN" you only send traffic to the AD over the VPN, with the "user VPN" you can send additional traffic over the VPN, or all traffic if so desired.

By the way, this is one possible approach, but perhaps @rozmansi has ideas on how to make it work more like what you describe.