~eduvpn/server#157: 
allow user override from "split" to "full" tunnel

Status
REPORTED
Submitter
~fkooman
Assigned to
No-one
Submitted
10 months ago
Updated
9 months ago
Labels
v3.x

~fkooman 10 months ago

Related: #155

~fkooman 10 months ago

What are the exact use cases for this? Why would a user want to turn a "split tunnel" profile into a "full tunnel" profile?

~fkooman 10 months ago

Is there a use case for the inverse? If a profile is "full tunnel", do we want the user to (easily) select which prefixes are routed over the VPN instead of everything?

~fkooman 10 months ago*

Limitations: not all servers will presumable allow "full tunnel", e.g. they may restrict the traffic that is not going to the advertised prefixes using firewalls. Do we need a configuration toggle for this in the server as well?

Also, the profile MUST have a DNS server configured, even if that is not used by 'split tunnel' configurations.

~fkooman 10 months ago

Additional Context: there currently are servers that duplicate profiles to have one be "split tunnel" and the other be "full tunnel", while being otherwise the same.

~fkooman 10 months ago

If we implement something like this, we could in the portal create a 'checkbox' next to "Prefer connecting over TCP (OpenVPN)", this only takes care of the portal obviously, but it might be an idea.

[ ] Prefer connecting over TCP (OpenVPN)
[ ] Always send all traffic over VPN

We may need to improve the text, e.g. "Prefer sending all traffic over the VPN", "Attempt sending all traffic over the VPN", ...

~fkooman 10 months ago

A rough idea on what needs to change in the generated configuration file. There is more, e.g. search domains, and for OpenVPN additional flags that are sent when "redirect gateway" is active.

#OpenVPN

route-nopull
redirect-gateway def1
dhcp-option DNS 9.9.9.9
dhcp-option DNS 2620:fe::fe

#WireGuard

[Interface]
...
DNS = 9.9.9.9,2620:fe::9
...

[Peer]
...
AllowedIPs = 0.0.0.0/0,::/0
...

~durnik 10 months ago

What are the exact use cases for this? Why would a user want to turn a "split tunnel" profile into a "full tunnel" profile?

We have users that are accessing external resources, so they need a university IP address, which is subscribed to that resource. Although many resources can be accessed with shibboleth, this is still used as well.

Is there a use case for the inverse? If a profile is "full tunnel", do we want the user to (easily) select which prefixes are routed over the VPN instead of everything?

We have an (expert) user who sets up multiple VPNs at the same time with different routing. It would be helpful to be able to specify routes when generating the config through the portal - saving one manual step.

~fkooman 10 months ago

We have users that are accessing external resources, so they need a university IP address, which is subscribed to that resource. Although many resources can be accessed with shibboleth, this is still used as well.

This one is rather easy to accommodate (in the portal), for apps it is a bit more complicated as that would require some kind of setting/toggle/popup on connect asking the user what to do, and a clear explanation to the users what that toggle would do.

From the perspective of the user it may make sense for this particular use case to have a profile called "Access to Research Papers", it wouldn't require 'duplicating' all profiles, just have this one "full tunnel" profile and have the rest be split tunnel...

We have an (expert) user who sets up multiple VPNs at the same time with different routing. It would be helpful to be able to specify routes when generating the config through the portal - saving one manual step.

I'm not really sure how to provide a (sane) interface to do this, perhaps this is too advanced to offer to normal users, perhaps providing documentation would be sufficient here.

~fkooman 9 months ago

Snippets from mail:


I'm suggesting the default is whatever defaultGateway is set to.

  • if defaultGateway = true

If it is true, the users will get the full tunnel profile by default. This obviously also already assumes DNS IPs are set.

If also a routeList is specified and contains some IPs, the user is allowed to choose split tunnel as well.

  • if defaultGateway = false

The split tunnel is the default in this case, if DNS IPs are specified, allow the user to choose full tunnel.

This not a 100% correct situation, because when DNS IPs are specified with a split tunnel profile, it might mean that those DNS servers are only used to resolve "local" names, and are not meant to be used to resolve all hosts, but yeah.

So I guess we are very close to matching the required behavior with this. The only option that might be nice to have is "allowDefaultGateway" as whether or not full tunnel is allowed can't always be interpreted reliably from the profile config...


For example, the UI could look like this, instead of now the selection box and the "Advanced" expanded area, it could be table that lists all profiles by name and instead has a "drop down" next to it that lists all the options (an advanced user) has. The portal is for advanced users anyway, so it doesn't have hide all details...

Both WireGuard and OpenVPN, and OpenVPN over TCP is supported as well:

     Students [ Default v ]
                [ OpenVPN ]
                  - Full Tunnel
                  - Full Tunnel (prefer TCP)
                  - Split Tunnel
                  - Split Tunnel (prefer TCP)
                [ WireGuard ]
                  - Full Tunnel
                  - Split Tunnel

Only WireGuard is supported, but supports both Full Tunnel and Split Tunnel

     Students [ Default v ]
                - Full Tunnel
                - Split Tunnel

No choice of protocol, no choice of split/full tunnel.

     Students [ Default ]

~fkooman 9 months ago*

Colleague came up with an idea to allow the user to set preferences (per profile?) in the portal if they prefer full tunnel / split tunnel (and perhaps also "prefer tcp". This could then also be used by the API, so no client modifications are needed.

~fkooman 9 months ago

I'm thinking now for simplicity reasons we keep the portal UI we have now, we just replace the advanced section with what is shown above where the profile title is the <optgroup> so we can get rid of the protocol selector and the prefer tcp checkbox and instead make that suboptions under the profile name.

~fkooman 9 months ago*

Step (1) is completed now where we got rid of the "Advanced" <details> toggle on the "Home" page. There is now just a single <select> box with <optgroup>'s.

Screenshot: https://argon.tuxed.net/fkooman/img/Screenshot%202023-10-09%20at%2015-57-23%20eduVPN%20-%20Home.png

Step (2) will be to add "full tunnel" / "split tunnel" if those options are available for that particular profile.

Register here or Log in to comment, or comment via email.