Use of IT tools with ZPA

My company is currently piloting ZPA and some common IT tools don’t work with ZPA enabled. I’ve seen similar topics related to this, but I’m creating this thread in the hopes of getting feedback from existing ZPA customers!

  1. How does your IT staff deal with ping being intercepted? The one workaround I know of is to install sysInternals PsPing. I suspect people won’t be happy to be unable to use the native ping operation.

  2. Nslookup is being intercepted by ZPA even though port 53 is excluded from all app segments. Why is this happening and if it’s expected behavior, how should IT staff perform DNS lookups when ZPA is in play?

Hi Katlyn,

I cant speak for other companies but yes traditional troubleshooting has to evolve when it comes to Zero Trust.
Zscaler Digital Experience (ZDX) is a essential part of that toolkit for us.

  1. ZDX gives us the full end-to-end view from the Endpoint (wifi strength, hops & latency) to the Public/Private Service Edge and the App Connector handling the request. Some additional improvements are on the way.

  2. Excluding port 53 is Zscaler best Practise to avoid pain. Does your IT Staff have access to the ZPA console ? If so have a look at the Diagnostic tab - Support Information.

Using this handy tool allows you to ensure that everything is working from the App Connector or App Connector groups as expected. This helps to rule out Firewall or DNS issues between the App Conn and Application.

Look forward to hearing from other community users.


100% agree with Gerhard. In a Zero Trust world, and how Zscaler applies segmentation, the user never gets the real IP address of the server and is never placed on the network.
NSLOOKUP would/should not return the real IP of the server, and is therefore of little use to the admin. ICMP should also be blocked.

Using the support portion of the admin interface, you can perform ICMP from the App Connectors to the applications. This would test RTT and ICMP responses from all the App Connectors to the server - which is more representative than doing it from the client.
Similarly - you can perform the DNS resolution from the App Connectors, and in a GSLB environment this would show you the responses from each App Connector.

If an application requires an ICMP response from a server to function (i.e. the app performs a PING before making a TCP Connection) then you can enable ICMP on the application segment. The response is representative of the path taken to reach the application (i.e. User->ZEN->AppConnector->Server)


100% agree ---- with the correct analysis of the ports and protocols needed ---- you can almost anything via an APP connector ---- and with the micro segmentation in use across Zscaler platforms ---- this is essential -------- the use of ZDX can improve your insight also -----

1 Like

In the case of my client, I created an effective “god mode” ICMP-enabled app segment and correlated access policy in ZPA to allow the client’s top level engineers to get to everything they need (switches, routers, non-domain servers, etc.) and use all tools they need to use (SSH/SCP, ping, etc.). The access policy is locked to both a dedicated AD group and a specific posture profile that matches only a specific subset of the Amazon WorkSpaces virtual desktops that get used for company business.

When ZCC is in use, NSLOOKUP will always show the CGNAT IP address (100.64.x.x) for an internal server if it is defined by name in an App Segment because the Zscaler cloud is the de facto DNS for Client Connector.