Below are best practices to follow if your users are running the Zscaler App in conjunction with a corporate VPN client.
If your users have a corporate VPN client installed on their devices in addition to the Zscaler App, Zscaler recommends you select Tunnel with Local Proxy or Tunnel with the filter driver as the forwarding profile action for all networks in your profile. This ensures maximum interoperability between the VPN client and the app.
Each platform has different requirements:
Use either Tunnel with Local Proxy mode or Tunnel mode with the filter driver.
Use only Tunnel with Local Proxy mode.
Zscaler App and any third-part VPN cannot run simultaneously, because the Android operating system only allows one concurrent VPN at a time.
Use Tunnel mode.
The iOS operating system allows multiple VPNs to run, as long as each VPN is a different type. Apple has three types of VPNs: personal, per-app, and enterprise.
Zscaler App runs as an enterprise VPN. To run other VPNs simultaneously with Z App, use personal or per-app VPNs.
Zscaler also recommends that you do not select Tunnel (route based) as the forwarding profile action for VPN Trusted Network. This is advised because VPN clients work at the network (IP) layer, which is the same layer the app works in if you select Tunnel mode. Both the VPN and the app working in the same layer increases the likelihood of interoperability problems.
Zscaler recommends selecting Tunnel with Local Proxy or (optionally) Tunnel with the filter driver for Windows as the forwarding profile action, because in these modes the Zscaler App works at the application layer. Users don't experience interoperability issues because the app is not competing with the VPN client at the IP layer. Instead, the app allows the VPN to take traffic as needed, but sets proxy settings or packet filters to ensures that all user traffic is still protected by Zscaler. If you are using app version 1.1.1 or later, you are not required to add a custom PAC file when selecting Tunnel with Local Proxy.
See more details about the different forwarding profile actions.
If your users have a corporate VPN, and you still decide to use Tunnel mode (route based) as your forwarding profile action, you must take some key steps to ensure that users do not experience connectivity issues. To learn more, see 4. Steps to Take if Selecting Tunnel (Route Based) for Forwarding Profile Action below.
The Zscaler App can work either at the network (IP) layer, or the application layer. You can specify which layer the app uses to tunnel traffic (or whether the app tunnels traffic at all) by selecting one of the following forwarding profile actions:
Even if you select Tunnel with Local Proxy as the forwarding profile action for VPN Trusted Network, you must ensure that the VPN client is not configured to change proxy settings on users' devices. If VPN clients tamper with proxy settings in any way, the Zscaler App does not forward traffic properly.
If your VPN doesn't set a default route, it's particularly important that you do not select Tunnel as the forwarding profile action. Zscaler recommends Tunnel with Local Proxy instead.
For ease of configuration, Zscaler recommends you select Tunnel with Local Proxy mode in this scenario. However, if you choose to run the app in Tunnel mode, and your VPN client is running in split-tunnel mode, you must take some steps to ensure the app interoperates with your VPN client. To learn more, see 4. Steps to Take if Selecting Tunnel for Forwarding Profile Action below.
If your VPN runs in full-tunnel mode, Zscaler strongly recommends against selecting Tunnel mode for the forwarding profile action.
If you select Tunnel mode as the forwarding profile action, and your VPN clients run in split-tunnel mode, the Zscaler App can only forward traffic properly if you allow traffic destined for the VPN gateway to bypass the app.
You can do this in the Hostname/IP Address bypass for VPN Gateway field when configuring your app profiles. Specify in that field the hostnames or IP addresses for all your VPN gateways. The app sets the routing table to exclude any traffic destined for the VPN gateway, ensuring that this traffic is allowed to bypass the app tunnel and properly go to the VPN. To ensure against connectivity issues, it is critical that you include all VPN hostnames or all IP addresses to which these hostnames might resolve.
On Windows devices, when the Zscaler App runs in Tunnel mode, the app sets the DNS on the interface to point to 100.64.0.3, 100.64.0.4, and 100.64.0.5. When a user launches a VPN connection, the app detects this network change and responds accordingly.
Upon launch, the VPN client sets its own DNS on the interface to make it the prioritized DNS for resolving internal domains. The Zscaler App detects this change and reverts it, so that 100.64.0.3 (Zscaler's DNS) is again the prioritized DNS for the user device. However, the app redirects any DNS query that comes to 100.64.0.3 to the original prioritized DNS (i.e., the VPN client DNS).
At this point, if the DNS query is for an external domain, and the original VPN DNS is configured only to resolve internal domains, the DNS query should continue to be redirected to the next DNS in the priority list, until it finds a server that can resolve the requested external domain.
However, some Windows programs do not redirect DNS queries to the next DNS in the priority list. In this scenario, the DNS query is unable to find a server to resolve the requested external domain, and the user is unable to reach the external domain. To prevent this, ensure that all VPN clients set the DNS so that they can resolve both internal and external domains.
To detect whether a network is a trusted, untrusted, or VPN-trusted network, the Zscaler App examines the network interface properties. Zscaler recommends selecting DNS Server and DNS Search Domains for trusted network criteria because they are static properties on the network interface.
In contrast, Host Name and IP resolution is a dynamic property, because the app must take the step of resolving a hostname to see if it resolves to the IP address specified in the Trusted Network Criteria. There is a chance that a resolution might fail because of network transition processes, or if a VPN connection is unstable. If a resolution fails, then the app can incorrectly determine the network is an untrusted one, in which case it applies the wrong forwarding profile action.
When a user launches a VPN connection, the app detects this network change and responds accordingly. If the VPN client runs in full-tunnel mode the app removes all of its own DNS settings to allow all traffic to properly go to the VPN. If the VPN client runs in split-tunnel mode, the app reconfigures DNS settings so it can properly apply the forwarding profile action for Off Trusted Network.
While that is the ultimate expected outcome, the user might experience some temporary network instability. When the app removes its own DNS settings, this is detected as a network change by the VPN client. In response, the VPN client might disconnect and attempt to reestablish the connection. The user might experience some connectivity issues until this process is complete and the app and VPN client reach equilibrium.