ZPA Connection troubleshooting


This is about detailed connection troubleshooting steps for ZPA (machine tunnel or user tunnel)… we have a scenario where the prelogin (machine tunnel) domain authentication isn’t working - the machine can’t contact the domain. ZPA Diagnostics says that the connection to domain controllers are successful and the domain controllers are reachable on the required ports from the app connectors. Are there are detailed logs and troubleshooting steps which can help in understanding the end to end connection flow and where the actual issue could be ?

Many thanks

Hi Ravi,

Have you seen this article below ?
Zscaler Private Access - Active Directory - :new: Secure Private Access (ZPA) - Zenith

We had a similar issue when we first started with Machine tunnel and the Packet capture did show I was missing ‘DNS SRV lookup’.

Once I added that everything worked


1 Like

Hi Gerhard,

Many thanks, so i did some further troubleshooting in the ZSA Tunnel logs on the endpoint. Essentially, it is able to perform DNS SRV lookups, so it is able to fetch all the domain controllers with the synthetic IPs in the response. After this, it tries to randomly pick once from the list and then does a UDP 389 LDAP query at which point it errors out with the below -

DBG ZPNUdpListener: send udp response : Length: 210
ERR ZPNUdpListener zpnUdpResponseCb Exception: I/O error: Bad address

And have no idea on what this error code means :slight_smile: !, after the above, the client keeps trying all other domain controllers and errors out all the time.

Not sure if you have ever seen the above error in your scenario ?


Hi Ravi,

Have you tried a Packet Capture ? (Thinking you might see drops or reason for constant DC rotation)
ZPA user tunnel is fine right…so we are not dealing with general OS FW right ?


What version client connector are you using? I’ve been slamming my head against the wall for the last few days dealing with the exact issue/error. In my case, I get that exact same error “bad address” using CC version It’s like it totally broke AD authentication while allowing everything else through, making me really think it was a config issue. I could ping, nslookup, rdp (as long as nla was disabled), telnet, etc-- but AD communication was broken. Reverting to fixed the issue for me. I also found that unchecking ipv6 on the nic would solve this issue. There is also a “prioritize ipv4 over ipv6” (which we have checked) in the app profile, which I haven’t experimented with. The documentation unfortunately fails to explain what the use case is for this setting…

1 Like

Hi Jason,

Many thanks, we are also on ! , we are also did further troubleshooting as in using LDP tool (with connectionless checked), from App connector to domain controller, the connection is perfectly ok, so essentially somehow either the app connector isn’t able to interpret the response back or rather the client connector itself is broken. Like you said, all TCP comms work perfectly fine but the problem with just with UDP…

Will try Also when you say uncheck ipv6, is it on the end point or app connector ?

Thanks again.

Yeah I’ve double confirmed now that this is some sort of issue with version Tested on two machines and each time reverting to fixed AD communication. On one I had to uncheck ipv6 on the tcp/ip stack of the endpoint to get working, and the only reason I tried that is because while testing connectivity I kept getting back ipv6 addresses (tested through a different isp/network vs the other endpoint). Not sure why that would have fixed it-- I already had “prioritize ipv4 over ipv6” enabled. And it isn’t really a “fix” anyways, cause I can’t disable ipv6 on all endpoints without causing other issues.

Based on my testing, when the endpoint is in this state very little traffic is returned by the app connector, and tests like test-computersecurechannnel or nltest all fail with “NO LOGON SERVERS”, even though you can poll/list all DC’s, srv records, etc.

1 Like