We need to add a warning that the RADIUS code is not audited in any way, it does work with what we tested, but no idea if it is actually secure.
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.
Snippets from mail:
I'm suggesting the default is whatever
defaultGatewayis 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
routeListis 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 ]
merged in the
v3branch, will be in the next release, either 3.4.2 or 3.5.0.
The quality of that daphp-radius is not great, but it does work (for now).
We have a working version now, tested against OpenBSD radiusd and PaDe's RADIUS server
initial untested work: https://codeberg.org/eduVPN/vpn-user-portal/src/branch/dapphp-radius
I think we have now all parts complete for a first version!
Initial documentation: https://codeberg.org/eduVPN/documentation/src/branch/v3/live-permissions.md
- LDAP + real time LDAP queries on API access, i.e.
- SAML + real time LDAP queries on API access, i.e.
We'll have to rework the permission system to make this possible, but it is not that much work. The difficulty is in not breaking existing deployments...