Device and Client controls

Prev Next

By default the user has full control over their device - including all the Client settings.

However, there are numerous configuration controls which allow the administrator to restrict/define the operation of the user's device, as well as the features that appear in the Client.

Use the Policies UI to create or change device/Client controls.

Device controls

Ringfencing

Ringfencing is designed to mitigate the security risk of transmission of malware between user devices such as laptops when they are sitting on a public network. Ringfence rules can block inbound and/or outbound local traffic except that which is required to establish the tunnel to the Gateways.

This is intended to be used when a user has their device in a 'hostile' environment such as a coffee bar or airport terminal. Advanced Ringfence can effectively make the device invisible as far as other users of the same public network are concerned. The tunneled traffic to the Gateways is encrypted, so this is also invisible while working on these public networks. And SPA renders the destination the user is connecting to invisible to other users. Together these allow users to operate in even the most hostile of environments such as a coffee bar or airport terminal with the highest levels of isolation possible.

If any of the user's device Policies contain Ringfence rules then the traffic in and/or out of the user's machine can be blocked according to the Actions set within these rules. It is important to note, as with most firewalls, all rules (including those set by AppGate ZTNA) have a priority set. The Client tries to set its Ringfence rules to have the highest possible priority, but locally installed firewall rules can override Ringfence rules. This is especially a problem with server operating systems where some rules may be set by the operating system to ensure the correct operation of the server. This means that Ringfencing should never be used to try to control east-west traffic between servers in a data center. East-west traffic should be controlled by third-parties (such as Illumio). AppGate ZTNA is designed to protect north-south traffic and the Ringfencing feature is included on a “best effort” basis specifically for the protection of devices on an untrusted, unprotected, hostile network.

NOTE

When applying Ringfence rules, they may result in some services becoming restricted for users e.g. instant messaging or IP telephony.

Device Proxy

Device Proxy will impose a PAC file on the device with the aim of helping to manage the outbound user traffic not destined for the AppGate ZTNA system. This might be used to filter the traffic destined for the Internet.

There are three alternatives ways for user's traffic to be handled:

  • The PAC file would normally be configured to handle the traffic NOT included in AppGate ZTNA Entitlements. Think of this as split tunneling where application traffic is handled by AppGate ZTNA and all the other traffic by the PAC file rules. This option allows the 'other traffic' to be directed to destinations outside the AppGate ZTNA system such as Cloud based SAS proxying service. Care needs to be taken when creating the PAC file rules to ensure traffic intended for the AppGate ZTNA system is not intercepted as the PAC file rules are applied before any AppGate ZTNA routes.

  • Where there is already a proxy server behind an AppGate ZTNA Gateway then the PAC file can be used in conjunction with an AppGate ZTNA Entitlement. In this case the 'other traffic' would be directed to an internal proxy behind a Gateway using an AppGate ZTNA Entitlement.

  • AppGate ZTNA itself can also be configured to handle the 'other traffic'. The Site settings Route all traffic through tunnel (Default Gateway) and Alternative default route for all user traffic can be used to direct this traffic to a default gateway behind a Gateway on a dedicated Site. In this case any specific AppGate ZTNA Entitlements are always applied before directing the remaining traffic to the default gateway.

When the device proxy is active the following changes are made by the appgate-driver to the registry:

Set: HKLM\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ProxySettingsPerUser = DWORD:0 (To let Windows know that the settings to be used are the ones set by the full client.)

Set: HKLM\Software\Policies\Microsoft\Internet Explorer\Control Panel\Proxy = DWORD:0 (To disable the proxy options in the Windows Control Panel so the user can not change the proxy settings while the Full Client is executed.)

Set: HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings = BINARY:<blob-including-pac-url-and-flags> (BINARY contains the actual proxy configuration.)

Refer to Apply Device Proxy for more details.

Client controls

Within the device Policy there are a number of configuration options which affect the behavior of the Client. Most of these are very self explanatory, however a couple of the controls deserve a little more explanation:

Client Features

Specific Client features can be hidden in the Client UI and then have their values pre-set by this Policy. See the AppGate ZTNA user guide for more details.

By using the Managed by Admin option, the user experience to be constrained which can suit some specific situations. This is done item by item; so if you check set attention level only, then that will be gone from the users UI; but everything else will remain as it was.

Client feature options including admin management settings for hiding various functionalities.