Difference between Tunnel and Tunnel with Local Proxy

Hello,

Would someone be so kind and explain to me like you would explain to a 5 year old what’s the difference between Tunnel and Tunnel with Local Proxy modes, and which option would be best suitable for us? We’re currently in the process of implementing Zscaler in our environment and we’re running into a few problem. I’m sure it would be better if we would have a better grasp of the whole thing.

I did of course read the documents and searched this topic on the forum, but I am still having problems understanding this.

First of all, let’s start with the background of our environment:

  • We are implementing a GRE tunnel to the Zscaler cloud on our internal network. So by default all traffic will go through it.
  • At the same time, we have an internal Squid Proxy that we still need to keep because some applications can only be accessed through it.
  • Which in general means that we have to use a PAC file to identify which traffic should go direct, and which traffic should go through the Squid proxy.
  • For remote Users, we will have IKEv2 VPN using Windows native “client” (specifically, Always-On VPN) implemented in a split-tunneling mode. Only corporate traffic will go over the tunnel, Internet traffic should go over Zscaler.

As of now I’ve been working on implementing a Tunnel with LP, but now I am not sure if this is what we should be doing.

The way I understand Tunnel with LP:

  • The Forwarding Profile PAC file is responsible for identifying which traffic goes to the ZAPP, and which goes elsewhere (either Direct or, in our case, to the Squid proxy)
  • Traffic to the ZAPP is done through a loopback interface
  • The ZAPP then forms a tunnel to the ZENs and pushes the traffic through it
  • Operates on the Application Layer

The way I undestand Tunnel (Filter Based)

  • Does not use the Forwarding Profile PAC file, but instead directs all traffic to the ZAPP using Windows Filter Driver
  • Does not use the loopback interface
  • The ZAPP then uses the App Profile PAC file to identify which traffic goes to the ZENs and which is directed elsewhere
  • Operates on the Network Layer

Is my reasoning correct? This is what’s confusing me. In both cases, the ZAPP needs to form a tunnel to the ZENs, but in one scenario it operates on Layer 7, in the second scenario it operates on Layer 4. How come?

In this document: https://help.zscaler.com/z-app/best-practices-zscaler-app-and-vpn-client-interoperability it is stated that the recommended option for split-tunnel VPNs is the Tunnel with LP. Why would I use that instead of the Tunnel (Filter Based)?

If I would select Tunnel (Filter Based) would I still need to apply the actions from Step 4, or is this only applicable for a Route Based Tunnel (which I don’t think I’m considering at this moment).

Many thanks in advance for your help on this topic.

Kind regards,

Wojciech

Hi, Wojciech!

Thank you for the detailed post. What you’ve stated is accurate, but just to simplify it:
In both Tunnel and tunnel with local proxy, routing to the cloud is determine by the App Profile PAC. think of this as more of a configuration file, rather than a PAC file.

The Forwarding profile determines how traffic gets to Z App from the applications on the machine, and the App Profile determines how traffic gets from Z App to the cloud.

So in summary, the transport from Z App to the cloud is the same in both modes. But how traffic is captured and sent to Z App changes depending on the mode.

In tunnel mode, we explicitly capture all 80/443 TCP traffic. Tunnel with Local Proxy, we capture all traffic that follows the system proxy. We generally recommend Tunnel with Local Proxy when using a VPN, purely because the VPN’s are either using a virtual network adapter, or also using a packet filter. In this way, Z App can ‘stay clear’ of the VPN.

In Step 4, this is mostly for route based mode correct. This is because in route based mode, Z app creates a virtual network adapter and configures the routing table to steer traffic to do this. This is also what the majority of VPNs do, so special configuration in step 4 is to make sure this functions as expected.

Regards

David

Thanks Dave. Making more and more sense now :slight_smile:
So, just to clarify - how ZApp forwards traffic to the cloud - does it build a TLS tunnel to ZEN and then multiplexes HTTP GET/POST requests across it, or does it treat ZEN as a proxy and sends each HTTP request outside of any tunnels directly to ZEN? What I am trying to understand is the following

Let’s say we have ZApp running on all our PCs, and we do want to use it even on prem to support seamless SSO. How do we bypass Internet-facing traffic on IPS engines that sit inline? Are we going to look for certain port, or are we going to look for certain destinations (ZENs) or do we have to do something else?

Regards

Hi Tymofii,

Good to see you on here.

The connection from Zapp to the cloud with Ztunnel 1.0 utilises an authenticated proxy connect tunnel to the ZEN. HTTP requests are sent within this proxy connect tunnel.

With Ztunnel 2.0 traffic is forwarded via a DTLS, and then falls back to TLS tunnel. All traffic, including non http/https traffic if forwarded is encapsulated within this DTLS, or TLS tunnel.

Thanks,
Dan

1 Like

Thanks @dhume.

So, let me summarize. If we use ZApp <2.0, then we are on ZTunnel 1.0. In this case Forwarding Method (Tunnel/Tunnel w/ Local Proxy, PAC) we chose is responsible to redirect traffic TO THE APP, but then Application establishes HTTP CONNECT tunnel to the ZEN and sends all HTTP(S) requests from the machine within this HTTP CONNECT tunnel?

Is it one tunnel for HTTP and HTTP(S)? If so, is it port 80, or custom port that ZApp uses? How can we identify these tunnel when user is on prem? So, we will use GRE + ZApp and we’d like to bypass traffic from ZApp from IPS inspection - how? :slight_smile:

I probably have to speak to Nick th then grab you for few hours :slight_smile: