Best Practices for Zscaler App and VPN Client Interoperability
Below are best practices to follow if your users are running the Zscaler App in conjunction with a corporate VPN client.
A. Select Tunnel with Local Proxy as the Forwarding Profile Action
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 as the forwarding profile action for all networks in your forwarding profile. This ensures maximum interoperability between the VPN client and the Zscaler App.
At the least, Zscaler recommends you do not select Tunnel as the forwarding profile action for VPN Trusted Network. Zscaler advises this 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 Zscaler App working at the same layer increases the likelihood of interoperability problems.
Zscaler recommends selecting Tunnel with Local Proxy as the forwarding profile action because in this mode, 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 to ensures that all user traffic is still protected by Zscaler. Note that if you are using Zscaler 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 Zscaler App can use.
If your users have a corporate VPN, and you still decide to use the Tunnel mode as your forwarding profile action, you must take some key steps to ensure that users do not experience connectivity issues. See D. Steps to Take if Selecting Tunnel 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) with the forwarding profile action you choose for forwarding profiles.
- In Tunnel mode, the App tunnels traffic at the Network (IP) layer. It captures user traffic by setting IP routes on user devices.
- In Tunnel with Local Proxy mode, the App tunnels traffic at the Application layer. It captures traffic by applying proxy settings on user devices. This option has advantages over the Enforce Pac option below because the App transparently handles authentication for users. This way, users don't have to reauthenticate for applications when they open new browsers and are less likely to run into issues accessing applications that aren't browser-based.
- In Enforce Pac mode, the App does not tunnel any traffic. It only sets proxy settings for browsers on the user device, and prohibits users from changing those proxy settings.
- In None mode, the Zscaler App does not tunnel any traffic at all. It performs no actions on the user device.
B. Ensure that VPN Clients Don't Change Device Proxy Settings
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 user devices. If VPN clients tamper with proxy settings in any way, the Zscaler App does not forward traffic properly.
C. Check if VPN Runs in Full-Tunnel or Split-Tunnel Mode
Your VPN can run in full-tunnel mode or split-tunnel mode. Each mode requires different configurations for the Zscaler App.
- In full-tunnel mode, all of a user's traffic is routed to the VPN client. When your VPN runs in this mode, the Zscaler App treats the network as a VPN Trusted Network. It applies the forwarding profile action you chose for that network in the forwarding profile. Note, however, the important caveats below:
- Zscaler strongly recommends against choosing Tunnel as the forwarding profile action for VPN Trusted Network. As explained above, because the Zscaler App in tunnel mode works at the same layer (IP layer) as the VPN client, interoperability issues have been observed with the App in this mode.
- The Zscaler App detects a full-tunnel VPN by looking for a default route in the routing table. If the VPN doesn't set a default route and uses a different mechanism to capture all user traffic, the Zscaler App doesn't consider the VPN a full-tunnel VPN, and therefore, doesn't treat the user as connected to a VPN Trusted Network. Instead, the Zscaler App treats the user as Off Trusted Network and applies the corresponding forwarding profile action. If your VPN doesn't set a default route, it's particularly important that you do not select Tunnel as the forwarding profile action. As noted above, Zscaler recommends Tunnel with Local Proxy instead.
- To detect a VPN Trusted Network, the Zscaler App also looks for the words Cisco, Juniper, Fortinet, PanGP, and VPN in the default interface description. If these words are missing, the Zscaler App treats the user as Off Trusted Network.
- In split-tunnel mode, only some of your user’s traffic is routed to the VPN client. For example, the VPN may set routes only for specific subnets, such as 10/8 or 192.168/16. Additionally, the VPN may set DNS on the device to capture traffic for internal hosts. If your VPN client runs in split-tunnel mode:
- The Zscaler App treats the device as Off Trusted Network and applies the forwarding profile action you chose for that network when configuring forwarding profiles for the App.
Again, for ease of configuration, Zscaler recommends you select Tunnel with Local Proxy mode in this scenario. However, if you choose to run the Zscaler 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. See the first item under D. Steps to Take if Selecting Tunnel for Forwarding Profile Action, below.
D. Steps to Take if Selecting Tunnel for Forwarding Profile Action
Should your organization decide to use the Tunnel mode, below are key steps to take to ensure users do not experience connectivity issues.
- If your VPN runs in split-tunnel mode, you must allow traffic destined for the VPN gateway to bypass the Zscaler App. See instructions.
NOTE: As mentioned above, if your VPN runs in full-tunnel mode, Zscaler strongly recommends against selecting Tunnel for the forwarding profile action.
If the VPN client runs in split-tunnel mode, ensure that any DNS used by the VPN can resolve both internal and external domains. See explanation.
- If your VPN has any firewall functionality, ensure that this functionality is disabled, or whitelist the Zscaler App in the firewall. Otherwise, the VPN firewall can interfere with Zscaler App tunnel processes.
- When you configure the Trusted Network Criteria in forwarding profiles, Zscaler recommends that you use the DNS Server and DNS Search Domains conditions. See explanation.
- Keep in mind that users may see some momentary network instability when a VPN client initially launches while the Zscaler App is running. See explanation.
VPN clients in Split Tunnel Mode
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 Zscaler 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 Zscaler 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.
Trusted Network Detection
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.
Hostname and IP resolution, in contrast, is a dynamic property, because the Zscaler 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 Zscaler App can incorrectly determine the network is an untrusted one, in which case it applies the wrong forwarding profile action.
Split Tunnel Mode - configure DNS properly
On Windows devices, when the Zscaler App runs in Tunnel mode, the Zscaler App sets 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 Zscaler App detects this network change and responds accordingly.
- If the VPN client runs in full-tunnel mode, the Zscaler 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 applies the forwarding profile action for Off Trusted Network in the forwarding profile. While this is the expected behavior, the following scenario has occasionally been observed when a VPN sets its own DNS on the interface, but the DNS is configured only to resolve internal domains.
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 Zscaler App redirects any DNS query that comes to 100.64.0.3 to the original prioritized DNS (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 DNS server next in the priority list, until it finds a DNS server that can resolve the requested external domain.
However, some Windows programs do not redirect DNS queries to DNS servers that are next in the priority list. In this scenario, the DNS query remains unable to find a DNS server to resolve the requested external domain, and the user is left unable to reach the external domain.
To prevent this, ensure that all VPN clients set DNS servers that can resolve both internal and external domains.
Network Instability when Launching VPN Connection
On Windows devices, when the Zscaler App runs in Tunnel mode, the Zscaler App sets 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 Zscaler 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 may experience some temporary network instability. When the Zscaler App removes its own DNS settings, this is detected as a network change by the VPN client. In response, the VPN client may disconnect and attempt to reestablish the connection. The user may experience some connectivity issues until this process is complete and the Zscaler App and VPN client reach equilibrium.