ZTunnel 2.0, Interception of non-HTTP ports, and logging

We migrated to Tunnel 2.0 a few weeks ago. For the most part, it’s worked out really well for us.

Today, I had a user say that his SSH connections (using Putty on Windows) were being routed through ZIA and due to IP restrictions on the remote end, he asked me to bypass it. Honestly, I didn’t think that we were tunneling SSH traffic through ZIA, but my own testing showed that we were.

Ultimately, I found that I could exclude that traffic by adding the IP to the “Destination Exclusion” list in the App Profile. I don’t like this approach, because I have quite a few app profiles, and it makes management a pain to have to add it to all profiles.

Furthermore, I couldn’t find any logs in ZIA or ZPA indicating this traffic was being processed by Zscaler at all!

So I have these questions:

  • Is there a more global way to exclude certain traffic from being tunneled?
  • What’s the point in tunneling the traffic if there aren’t any logs of the traffic? Am I missing something here?
1 Like

Save yourself the headache and build a global policy instead of a bunch of different ones.

As far as the logs are concerned i believe you need the advanced firewall module to be able to see thise (found this while digging myself a few months ago in my orgs beta cloud)

This is correct, you need advanced CFW to see all logs, otherwise you will only see blocked logs and allowed traffic will be summarised.

This said, for @justintime’s scenario, on Windows platform, you can exclude traffic form Zscaler Client Connector based on destination port. E.g. exclude 0/0:22 in the App profile. This is documented here --> https://help.zscaler.com/z-app/best-practices-adding-bypasses-z-tunnel-2.0

Its almost like I’m a Zscaler fanboy knowing all this stuff! :rofl::rofl::rofl:

1 Like

+1 for the global exclusions in App profiles. We tried the global App policy approach in ZIA and it just doesnt work for us as we are global and have many variations in countries, particulary APAC.

I had something similar to you around port 22 but fortunately we have VZENs running internally which have our own IPs to be used for exactly this purpose, where a particular source IP for SSH is required.

We looked at excluding port 22 entirely as @skottieb suggested but decided against it as its a security risk. Our devs were connecting to public IPs that constantly changed, so we had no way of pinning down the IPs for a more specific exclusion.

You could also just create a “Basic Firewall” rule to allow SSH. The default rule will block it.