Hi everyone, I’m diving into my first ZPA deployment for a SaaS evaluation project and I’ve hit a wall that’s got me stumped.
Everything *looks* like it should work. My connector shows as healthy and “connected” in the admin portal, and my test device has the Z App with a solid “connected” status. But when I try to reach the internal application I set up, it just times out. No error page, nothing. It’s like the tunnel is open but the road inside is blocked.
I’ve double-checked the obvious things from the docs:
- The application segment’s DNS name matches.
- The connector group and server group seem correctly linked.
- The test user is in the correct access policy.
I’m wondering if there’s something less obvious I’m missing. Could it be a port conflict on the server side, or maybe a subnet overlap issue? Or is there a specific log view in the ZPA admin that’s more telling than just the connector health status? I’m also curious if anyone has run into this during a trial phase—maybe a common setup pitfall with private IP ranges?
I’d really appreciate any pointers on where to look next. Feeling a bit lost after staring at green checkmarks all day!
New here!
Just my two cents.
The connector health status is a generic liveness check, it doesn't verify the actual data plane path. Your timeout points to a routing or firewall issue between the connector and the application server.
You need to look at the ZPA admin logs under Monitoring > Troubleshooting. The "Connection Details" and "Transaction Details" logs for your app segment will show the attempted flow. Focus on entries where the status is "ACCESS_DENIED" or "CONNECTION_TIMEOUT". These will tell you exactly where the packet was dropped.
It's often a local OS firewall on the app server itself. The connector initiates the connection from its own IP, not the user's device IP. If your internal server's firewall only allows its own subnet, it will block the connector.
numbers don't lie
User406 gave you the right starting point with the Troubleshooting logs. Those connection details are crucial. I'd just add that in a trial setup, the most common cause I've seen for this exact symptom isn't a server firewall, but the connector's own network path.
The connector needs outbound access to the ZPA cloud *and* a route to your internal application server. A "connected" status only confirms the first part. Can the connector machine itself ping or reach the app server on the required port using its local network? If there's a proxy in your test environment that's required for internal traffic, the connector might not be aware of it.
Also, double-check the application segment's "Default Domain" field. If that's incorrectly set, the connector might be trying to resolve the app's name to an external address instead of the internal one you've defined in the server group.
read the contract
Good catch on the connector's internal route, but that's only half the battle. If the connector can ping the server but the app still times out, you're likely dealing with a TCP handshake that dies at the service port.
The connector's health check is a joke. It'll show green if it can phone home, even if its local routing table is a mess. I've seen it pass while the connector VM was in a subnet with no route to the app server's VLAN. Default gateways matter.
Trust but verify
You're getting solid advice here. Green checkmarks in ZPA only mean control plane connectivity. The data plane is a separate beast.
Since you're in a trial, check the connector VM's local route to your app server first. Can it reach the server's IP and port from its own network interface? A simple telnet from the connector can rule out the most basic routing or host firewall block.
Also, don't overlook the "Default Domain" in your application segment. If that's wrong, the connector will fail to resolve the address you're trying to reach, even if everything else looks perfect.
—AF
Ah, the classic "green but broken" ZPA scenario. Been there!
All the advice about checking connector logs and local routes is spot on. Since you're in a trial, I'd bet a coffee it's one of two things:
1. The "server group" IPs are wrong. Double-check that the private IPs listed there are exactly what the app server uses, and that the connector can actually reach that subnet. A screenshot of that config tab might help.
2. A local OS firewall (like Windows Defender Firewall or iptables) on the app server itself is blocking the connector's IP. The connector initiates the connection, so the server sees traffic coming from the connector's private IP, not the user's. That often trips up trial setups.
Can you run a quick `telnet ` from the connector's command line? That'll tell you instantly if the basic TCP path is open.
Dashboards or it didn't happen.