Static Permissions#
You can use a (JSON) file where the mapping between permissions and users or IP prefixes are stored.
This file needs to be stored in /etc/vpn-user-portal/static_permissions.json
.
These permissions will be available for accessPermissionList
,
aclPermissionList
and adminPermissionList
, see
Permissions for more information on actually using the
permissions.
If the file /etc/vpn-user-portal/static_permissions.json
does not exist,
there will be no “Static Permissions”.
User Permissions#
The JSON file has the following format:
{
"memberOf!employees": [
"ellis",
"remi",
"charlie"
],
"memberOf!admins": [
"charlie"
],
}
This means that the users ellis
, remi
get the permission
memberOf!employees
and the user charlie
gets both memberOf!employees
and
memberOf!admins
.
Network Permissions#
NOTE: available in vpn-user-portal >= 3.5.6
NOTE: (2024-03-14) we are considering removing this functionality again as it turns out in practice it is very confusing as you can get different “views” if you log in multiple times, also the list of limitations is huge!
It is possible to assign permissions based on the originating IP of the VPN application (or browser) by specifying IP prefixes. This can be used to only allow access to certain VPN profiles from e.g. the office network.
NOTE: See Limitations!
{
"ipv4-clients": [
"IP@0.0.0.0/0"
],
"ipv6-clients": [
"IP@::/0"
],
"lan-devices": [
"IP@10.160.220.0/24",
"IP@fddb:afbb:4726:8a6d::/64"
]
}
In the example above, if a VPN client arrives over IPv4, it will get the
permissions isMemberOf!ipv4-clients
, when it arrives over IPv6 it gets
isMemberOf!ipv6-clients
. If the VPN client’s IP is contained within the
ranges 10.160.220.0/24
OR fddb:afbb:4726:8a6d::/64
it will get the
isMemberOf!lan-devices
permission.
Limitations#
It is important to take the following limitations in consideration before implementing IP based restrictions:
- The VPN client IP address is (by default) ONLY checked at the exact moment the user authenticates to the portal, or authorizes the VPN application, and then cached until Session Expiry;
- Live Permissions MUST be used in order to verify the VPN client’s IP “on connect” when using the VPN applications;
- Even with Live Permissions, the check is NOT performed when the user does not interact with the VPN application, for example when a user roams with their laptop from the office to home, the originating IP address is NOT verified when that happens;
- If the user downloads a VPN configuration through the portal from an IP address for which access to the VPN profile is allowed, this configuration can be used until it expires, there will be NO additional checks “on connect”, also not when using Live Permissions;
- Additional steps MUST be taken to prevent VPN connections from being established from outside the allowed networks, for example by using firewall rules restricting access to the OpenVPN port(s);
- Using a firewall for WireGuard connections does NOT work without deploying an additional node for the “restricted” profiles, otherwise filtering will prevent access to ALL profiles if some are “unrestricted”;
Depending on the scenario, it MAY be possible to create a more or less “safe” solution, but you really have to know what you are doing! Contact us if you want to discuss your exact scenario!
Configuration#
There are a few configuration options that can be set in
/etc/vpn-user-portal/config.php
, their default values are shown:
[
// ...
'StaticPermissions' => [
'permissionsFile' => '/etc/vpn-user-portal/static_permissions.json',
'defaultAttributeName' => 'memberOf',
'isLivePermissionSource' => false,
],
// ...
Configuration Key | Type | Default | Description |
---|---|---|---|
permissionsFile |
string |
/etc/vpn-user-portal/static_permissions.json |
Location of the JSON file containing the permissions |
defaultAttributeName |
string |
memberOf |
If no attribute name “prefix” is specified in the JSON file, e.g. memberOf! this will be the default |
isLivePermissionSource |
bool |
false |
Use this source for Live Permissions |