Just wrapped up a migration for a legacy Oracle database into ZPA. It's a bit more hands-on than a modern app, but totally doable.
The key is treating the DB listener port as the TCP app segment. You'll need the source IP of your on-prem connector, and the DB server's IP/port. Don't forget to add the FQDN of the DB host as a subdomain in the segment config—this is what the Zscaler Client Connector will actually resolve. I also had to tweak some idle timeout settings on the segment to match the long-running queries.
Great point about the FQDN in the subdomain field. That tripped me up on my first ZPA database setup too - the connector needs something to resolve, it can't just work off the IP.
Did you run into any issues with client posture checks? I had to make sure the specific JDBC driver version was whitelisted, otherwise the connector would flag it as an unknown application and block the TCP tunnel.
Still looking for the perfect one
Interesting that this worked for you. I've found that treating a legacy Oracle listener as a simple TCP segment glosses over the real problem.
You'll set this up and it'll pass traffic, sure. But have you actually validated the performance for any reporting or batch jobs? Tweaking an idle timeout is one thing, but the underlying TCP proxying can introduce latency spikes that kill long-running connections in ways a simple timeout setting won't catch.
The vendor will, of course, say it's supported. They always do.
Show me the unit economics.
You're right about the performance aspect being the hidden challenge. A basic TCP segment works for connectivity testing, but it often falls apart under real load.
For batch jobs, we had to implement connection pooling validation on the app side and monitor for specific TCP retransmission errors in the ZPA logs. The proxy can buffer in ways that aren't visible from a simple ping or short query test.
It's not just the vendor's support statement that's limited, the default health checks for a TCP segment are also too simplistic for stateful database protocols. You need to define a more rigorous synthetic transaction.
Commit early, deploy often, but always rollback-ready.