Private apps without an inbound port.
A private application stays on your network with no inbound port of its own. A connector beside it dials out to the broker, and each request or connection is decided for that application. Pramaan has four ways in, and each runs only when you switch it on.
The connector dials out
The connector runs inside your network, beside the application. It dials out to the broker and opens no inbound port, and it relays only to targets on its own approved list.
For a web application, the broker matches the address a browser asks for against your registered private apps, checks the person's sign-in, their groups and your access rules, then relays the request over that app's connector.
The application has no inbound port; the broker's own entry points do. In our reference deployment the connector listener and the raw-TCP ingress, :9445 and :9446, accept connections from the internet, each behind source-address connection limits that our host applies: guarded, not hidden. The desktop client's UDP tunnel is also published, behind a token and an address check instead. On your own host, those limits are yours to set up.
Direct connections for SSH, RDP and Postgres
Browsers speak HTTP, so other TCP traffic goes through the raw-TCP ingress. A forwarder on your computer opens a local port and carries each connection to the broker, which hands it to the application's connector. Each connection is checked on its own: the access token, the person's groups and your access rules.
The recipe from our documentation, for an SSH server registered as the raw-TCP application ssh-vm: point the forwarder at the ingress, sign in, and forward a local port, then connect your SSH client to the forwarded local port.
export PRAMAAN_TCP_TUNNEL_ADDR=id.example.com:9446 # the raw-TCP ingress
pramaanctl login
pramaanctl forward ssh-vm 2222 # opens 127.0.0.1:2222Denied unless a rule allows it
Each private application is denied unless an access rule allows it: being in the application's group is not enough on its own. If the broker cannot read the rules, or its identity store is unavailable, the request is denied as well. On the raw-TCP ingress, an application with no group assigned, a verdict that asks for inspection and a verdict that asks for step-up are also refused.
What this does not show: a measurement; the topology is illustrative.
Text version
| App | VPN: network membership | Per-app ZTNA |
|---|---|---|
| App 1 | Reachable | Reachable |
| App 2 | Reachable | Reachable |
| App 3 | Reachable | Not reachable |
| App 4 | Reachable | Not reachable |
| App 5 | Reachable | Not reachable |
| App 6 | Reachable | Not reachable |
| Total | If this laptop is compromised: 6 apps reachable | If this laptop is compromised: 2 apps reachable |
Ending access reaches live raw-TCP connections. Deactivate a person, or disable, re-scope or remove a raw-TCP application, and the live raw-TCP sessions it covers are cancelled, not merely refused next time.
Sites
Multi-site routing places an application in a site, a routing domain of its own: the broker picks a connector in that site whose routes best cover the application's address, so overlapping private addresses in different sites do not collide. By default, only routes an administrator declares carry traffic, unless you choose to trust the routes connectors advertise.
Questions
Does the application need a public address?
No. Its connector dials out to the broker and opens no inbound port. The reachable part is the broker's listeners, and in our reference deployment they are each behind source-address connection limits.
Is the broker hidden from the internet?
No, and we do not describe it that way. A published listener accepts connections; the broker checks each one before any application is reached. Guarded, not hidden.
Can a phone forward SSH or a database connection?
No. Forwarding runs in the Pramaan desktop app only: the Android app lists raw-TCP apps and does not forward them.
Does device posture apply to raw-TCP connections?
No. On the raw-TCP ingress device posture is unknown, and a rule that requires a trusted or limited device tier never matches there; if no other rule allows the connection, the default deny refuses it. Write rules for raw-TCP applications on groups, not on device tiers. If unknown-posture fail-closed is on (off by default, or the administrator's posture setting), the rule that allows the connection must also list the unknown device tier, or the connection is refused.
What happens when no access rule matches?
The request or connection is refused: each private application is denied unless an access rule allows it. If the broker cannot read the rules, or its identity store is unavailable, the request is denied as well.
Talk to us, or try it first
-
Book a walkthrough
Against your own apps, not slides.
-
Run the lab
It uses a demonstration account; none of your data is involved.
-
See pricing
Published floors, named-user bands and what every tier includes.