About Knox VPNs

Although device users have the option of configuring VPNs through the Android Settings menu, in larger enterprise settings, IT admins use their EMM consoles to configure VPNs for many devices at once. Admins can also create a VPN profile and apply it to groups of users.

In configuring VPNs, admins require a good understanding of the configuration choices available on a given device. The configuration choices are based on factors such as the following:

• Are the apps that need VPN connections inside or outside a container?
• Which apps are required to use VPN connections as determined by the IT admin?
• Which apps can connect to the network directly, bypassing the VPN, as determined by the IT admin?
• Is the device corporate owned or a BYOD?
• Which advanced Knox VPN features should be used?

Since Knox 3.2.1, VPN is optimized for deployment to large numbers of apps.

Advanced Knox VPN features

Here are the advanced VPN features provided by the Knox platform:

• Per-app VPN: The admin can set a policy to make sure that the traffic from a single app, or a set of apps, is routed through VPN.
• User-wide VPN: The admin can set a policy to make sure that the traffic from the entire user is routed through VPN. Starting with Knox 3.2.1, on devices where a User-wide VPN is active, IT admins can add specific apps to a blocklist. Adding apps to the blocklist exempts the specific app from using the VPN tunnel to connect to the network and exchange data. For more information, see Blocked apps.
• Device-wide VPN: The admin can set a policy to make sure that the traffic from the entire device is routed through VPN. To set this policy the admin should be the owner of all the non main-users (Knox users) and the VPN client needs to be installed in either user 0 or main user.
• On-demand connections: The admin can set a policy to start and stop the VPN connection only when the apps added to the VPN profile are launched or closed. The policy is applicable to only per-app use-cases.
• Chaining VPN servers: The admin can set a policy to doubly encrypt the data-traffic from apps added to the VPN profile. The admin should have two different VPN clients supporting the Knox VPN framework. The policy is applicable on the per-app, per-user, or per-device wide use-cases. Both the VPN clients need to be installed in the same user space. The flow is structured as follows: Apps generate traffic which is handled by VPN client 1, then by VPN client 2, then by the Device Physical Network interface [WIFI/Mobile], then by VPN server 2, then by VPN server 1 before heading to the traffic destination. For more information, see the VPN chaining page.
• Embedded UID/PIDs: The admin can set a policy to embed the end-point details, such as UID and PID, in IPv4 data packets. Cisco AnyConnect is the only VPN client which currently supports this feature. The policy is applicable on the per-app, per-user, or per-device wide use-cases.
• Static HTTP proxy: This policy is applicable on the per-app, per-user, or per-device use-case.
  • No authentication proxy: The admin can set a policy to route the HTTP/HTTPS traffic through a proxy server present behind the VPN server before reaching the actual destination. The proxy server configured by the admin during profile creation has no authentication.
  • Basic authentication proxy by admin: The admin can set a policy to route the HTTP/HTTPS traffic through a proxy server present behind the VPN server before reaching the actual destination. The proxy server configured by the admin during profile creation has basic authentication. The authentication details are provided by the admin during profile configuration.
  • Basic authentication proxy by end-user: The admin can set a policy to route the HTTP/HTTPS traffic through a proxy server present behind the VPN server before reaching the actual destination. The proxy server configured by the admin during profile creation has basic authentication. The device user enters the login credentials when pesThe authentication details are provided by the end-users when a pop-up is provided by the system.
• PAC HTTP proxy support: This policy is applicable on a per-app, per-user, or per-device wide use-cases.
  • No Auth: The admin can set a policy to route the HTTP/HTTPS traffic through a proxy server present behind the VPN server before reaching the actual destination. The selection of proxy server is based on the original destination of the traffic as mentioned in the PAC URL. The proxy server selected has no authentication.
  • Basic/NTLM authentication provided by admin: The admin can set a policy to route the HTTP/HTTPS traffic through a proxy server present behind the VPN server before reaching the actual destination. The selection of a proxy server is based on the original destination of the traffic as mentioned in the PAC URL. The framework supports a proxy server which can be authenticated through basic or NTLM authentication. The authentication details are provided by the admin during profile configuration.
  • Basic/NTLM authentication provided by end-user: The admin can set a policy to route the HTTP/HTTPS traffic through a proxy server present behind the VPN server before reaching the actual destination. The selection of a proxy server is based on the original destination of the traffic as mentioned in the PAC URL. The framework supports a proxy server which can be authenticated through basic or NTLM authentication. The authentication details are provided by the end-users when a pop-up is provided by the system.
• Traffic blocking: When VPN is down, the Knox VPN framework will block both DNS and data traffic originating from the apps added to the VPN profile. When VPN is up, and if the VPN interface supports only IPv4, IPv6 data traffic originating from the apps added to the VPN profile will be blocked and vice-versa.
• Android Settings-based VPN configuration: Basic VPN configuration through the Settings menu can support Knox VPN features such as on-demand, per-app, device-wide, user-wide, static and PAC Proxy connections.
• IPv4 and IPv6 formats: The Knox VPN framework supports both IPv4 and IPv6 tunnels.
  • Both a static proxy server can be represented with an IPv6 address and a domain name can be resolved to an IPv6 address as long as the VPN interface supports the IPv6 address format.
  • Both a PAC URL can be represented with an IPv6 address and a domain name can be resolved to an IPv6 address as long as the VPN interface supports the IPv6 address format.
  • Both a proxy server mentioned in the PAC URL can be represented with an IPv6 address or a domain name can be resolved to an IPv6 address as long as the VPN interface supports the IPv6 address format.
    
• Multiple VPN tunnels: Multiple VPN clients can be active at the same time in the same user space. The Knox VPN framework supports VPN clients which support multiple VPN tunnels.

VPN Requirements

• A VPN client integrated with the Knox VPN framework installed on the device.
  • See VPN Clients That Implement the Knox VPN Framework for a list of clients from which you can choose.
  • See also Optional Knox VPN APIs for Third-Party VPN Clients for a list of APIs which may, or may not be implemented by third-party vendors.
• The vendor-specific parameters for third-party VPN clients that help define the VPN profile.
• A valid Knox license with VPN permission "com.samsung.android.knox.permission.KNOX_VPN_GENERIC"
• It is also possible to control basic VPN configuration through the Android O Settings screen. In this case, the add-on VPN Client APK must be downloaded from Samsung and installed in main user.

App and Device VPN Configuration With a VPN Profile

VPN profiles can control the VPN configuration for a given app and device, depending on the EMM agent's permissions. Once an application is assigned a VPN profile, the app cannot be assigned a second, different profile. The initial profile must be removed and then the new profile can be assigned.

Once a VPN proxy is configured for an app, the proxy also covers mobile data for the device.

The following descriptions explain what types of VPN profiles the Knox VPN framework supports.

A Per-App Profile

A per-app profile lets all the traffic from apps which are added using any of the following API to tunnel through VPN :

• GenericVpnPolicy.addPackagesToVpn
• GenericVpnPolicy.addAllContainerPackagesToVpn

A User-Wide Profile

A user-wide profile lets all the traffic from apps which are added using any of the following APIs to tunnel through VPN:

• GenericVpnPolicy.addAllPackagesToVpn
• GenericVpnPolicy.addAllContainerPackagesToVpn

Blocked apps

Starting with Knox 3.2.1, devices running a user-wide VPN profile can have blocked apps, that is, apps that do not connect using VPN. None of the Knox VPN features such as Proxy, chaining, and uid/pid are applicable to such blocked apps. When a user-wide VPN profile is in use, the following is true for all blocked apps, whether the user-wide VPN is running or not.

• Add a list of blocked apps to Enterprise.db.
• Send DNS queries using the physical interface.
• Send and receive data packets using the physical interface.
• Download files using the physical interface for Download Manager operations.
• Stop the framework from sending proxy related information to the apps.

The Knox SDK includes the following APIs to help IT admins manage blocked apps.

addPackagesToVpn	removePackagesFromVpn
addAllPackagesToVpn	removeAllPackagesFromVpn
addContainerPackagesToVpn	removeContainerPackagesFromVpn
addAllContainerPackagesToVpn	removeAllContainerPackagesFromVpn

The following describes the process that the blocked apps follow when a user-wide VPN profile is in use.

1. The device user searches for and tries to download an app through the Playstore app.
2. The Download Manager app receives the download request and tries to make a dns query for the download URL.
3. Before sending the DNS query, the Download Manager app sends a query to the system_server—including uid of the originator, in this case the Playstore app—through the Unix domain socket to find the network interface used to send the query.
4. From its cache, the system_server learns that the Playstore app is exempted from going through VPN and instructs the Download Manager app to send the request to netd through the network interface with the ID 498.

   Note: The network interface ID is a pre-defined constant and belongs to the Knox VPN range of 100 to 500.

5. The netd app then sends the query through the default physical interface, such as wlan0 or rmnet0.
6. For all apps marked with the ID 498, all data requests are sent directly without going through the VPN.

A Profile for Android O VPN management for Knox

A profile which allows the use of basic VPN controls present in the Settings menu supports Knox VPN features such as proxy support, on-demand, per-app, user-wide, or device-wide VPN. See also Requirements for the required APK needed for this type of configuration.

Knox VPN APIs for third-party VPN clients

The following APIs in the Knox SDK GenericVpnPolicy class may, or may not, be implemented by third-party VPN clients. EMMs whose agents make use of the features provided by these APIs must verify that the third-party VPN clients that a given enterprise is using and has implemented these calls.

• setVpnModeOfOperation
• getVpnModeOfOperation
• setUserCertificate
• getUserCertificate
• setCACertificates
• getCACertificate
• setServerCertValidationUserAcceptanceCriteria
• setAutoRetryOnConnectionError