Access a private service without opening the network

The problem

A traditional VPN often grants more network access than the task requires. Publishing the service instead creates an internet-facing surface that must be protected.

Choose and scope the connection model

Place a publisher near the service, then choose the connection model for the consumer. The full client suits people who need native tools and private names. wzctl suits processes that can use a local port.

1. 1Deploy a publisher that can reach the private service.
2. 2For direct access, assign the user through a group and connect the full WireZTNA client.
3. 3For process access, run wzctl with the publisher ID, exact target IP, TCP port, TTL, and local port.
4. 4Use the private hostname or IP with the full client, or 127.0.0.1 with the access pass.

When this pattern fits

• A person needs normal SSH, database, RDP, HTTPS, or Kubernetes access.
• An agent, CI job, or integration can use one local TCP port.
• The destination must stay private and should not accept internet traffic.
• The required authorization can be expressed as CIDRs or explicit host-and-port rules.

Security boundary and limitations

• The full client routes the publisher CIDRs authorized through the user's groups. Limiting it to one host and port requires an effective restricted policy and AccessRule.
• A wzctl pass carries TCP to one exact IP and port. It provides no private DNS, UDP, ICMP, or general network routes.
• WireZTNA controls reachability. The destination still enforces its own credentials, roles, certificates, permissions, and audit policy.