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 profile. This ensures maximum interoperability between the VPN client and the app.

Zscaler also recommends that you do not select Tunnel 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 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. 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.

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:

In Tunnel mode, the app tunnels traffic at the network (IP) layer. It captures user traffic by setting IP routes on users' devices.

In Tunnel with Local Proxy mode, the app tunnels traffic at the Application layer. It captures traffic by applying proxy settings on users' devices. This option has advantages over the Enforce PAC option 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 users' devices, and prohibits users from changing those proxy settings.

In None mode, the app does not tunnel any traffic at all. It performs no actions on users' devices.

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.

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 app treats the network as a VPN Trusted Network. It applies the forwarding profile action you chose for that network in the forwarding profile. However, the following important caveats apply:

Zscaler strongly recommends against choosing Tunnel as the forwarding profile action for VPN Trusted Network. Because the app in Tunnel mode works at the same layer (IP layer) as the VPN client, interoperability issues can occur with the app in this mode.

The 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 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 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. Zscaler recommends Tunnel with Local Proxy instead.

To detect a VPN Trusted Network, the app also looks for the words Cisco, Juniper, Fortinet, PanGP,and VPN in the default interface description. If these words are missing, the app treats the user as Off Trusted Network.

In split-tunnel mode, only some of your users' traffic is routed to the VPN client. For example, the VPN might set routes only for specific subnets, such as 10/8 or 192.168/16. Additionally, the VPN might set the DNS on the device to capture traffic for internal hosts. If your VPN client runs in split-tunnel mode the app treats the device as Off Trusted Network and applies the forwarding profile action you chose for that network when you configured the forwarding profile.

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 D. Steps to Take if Selecting Tunnel for Forwarding Profile Action below.

If your organization decides to use Tunnel mode, the following key steps apply in order 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.

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 more details.

If your VPN has any firewall functionality, ensure that this functionality is disabled, or whitelist the app in the firewall. Otherwise, the VPN firewall can interfere with app tunnel processes.

When you configure the Trusted Network Criteria in your forwarding profiles, Zscaler recommends that you use the DNS Server and DNS Search Domains conditions. See more details.

Keep in mind that users might see some momentary network instability when a VPN client initially launches while the app is running. See more details.

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.

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 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 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 IPresolution 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.

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. 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.