Reach a Workstation Behind NAT Without Port Forwarding
A workstation with no inbound port is still reachable through a hub, a relay or an app broker. Compare what each design guarantees before you pick one.
Two endpoints behind carrier NAT and a locked-down office router leave no inbound port to forward, and the reflex is to request one anyway. The better question is which side can dial out and which reachable service is allowed to carry the traffic. Four designs answer that question differently, and they fail in different ways when a path is blocked. Choosing among them is a comparison of guarantees, not of protocol names.
Four designs, four different promises
The table below is the short version. Read the middle column as the promise you can test, and the right column as the promise nobody made.
| Design | Who initiates | Promise you get | Promise you do not get |
|---|---|---|---|
| Routed VPN hub | Both ends, outbound to the hub | A routed path to permitted prefixes | Access to services no policy allows |
| Peer traversal with ICE | Both peers to a rendezvous service | A path tested between the two peers | A direct path through every NAT |
| TURN relay | Client outbound to a relay | Transport that survives symmetric NAT | Peer discovery or a usable directory |
| Application broker | Workstation outbound to a broker | One audited application session | Subnet-wide reachability |
Which row applies depends on the task rather than on preference. One remote desktop session, one administrative shell and access to an entire private subnet are three requirements that do not need the same entry point, even when they happen to involve the same machine.
A hub changes who dials out, not what is allowed
In a routed hub design the remote laptop and the workstation, or the site gateway in front of it, each open an outbound tunnel to a service that both can reach. Nothing accepts an unsolicited connection at the workstation's router, which is exactly why this design survives NAT and why it still works when the site has no static address. The hub then routes traffic between the two inner addresses according to its own policy.
The cost is that the hub must exist, must be reachable from both sides, and must be operated by someone. Outbound filtering has to permit the transport, and a network that blocks it will defeat the design even though no port forward was needed.
The subtle part is that reachability and authorization are separate decisions taken in different places. A route into a prefix says nothing about which service on the workstation the identity may use, and a firewall rule that permits the tunnel says nothing about whether the account can log in. Configure both, test both, and keep the authorization decision with the system that owns the resource rather than with the routing table.
Traversal works only when both stacks implement it
Peer traversal is a capability of a specific system, not a setting that improves a VPN. Interactive Connectivity Establishment gathers several candidate addresses and tests pairs until one works: host candidates on local interfaces, server-reflexive candidates built from what a NAT reveals, and relayed candidates allocated on a relay. A private address on its own is not a path, because the other side cannot route to it.
The relayed case is worth understanding before dismissing it. RFC 8656 describes TURN as a protocol in which a client asks a server for a relayed transport address and the server forwards traffic between that client and its peers. The relay therefore carries the data, which is materially different from a directory that only helps endpoints meet. Exchanging the relay address with the peer is a coordination step that the application has to perform.
What you cannot promise is a direct path. Symmetric NAT and some enterprise firewalls defeat hole punching, and when they do, the system either falls back to a relay or fails. What you also cannot conclude is that two translated endpoints can never talk; a supported stack with a relay fallback exists precisely because they often can. Decide whether availability or directness matters more, then verify which path the deployment actually selected instead of assuming the happy case.
A broker is narrower than a network
When the requirement is one application, an application broker or a reverse connection started by the workstation can be the smallest answer. The workstation dials out to a broker, the broker authenticates the remote user, and only that application session is carried. No route to the workstation's subnet is created, so a compromise of the remote session does not inherit a path to every device beside it.
That narrowness has a price: every additional application needs its own integration, and anything the application assumes about a local network, such as a file share it opens on a nearby server, may not be reachable. Brokers also concentrate policy and logging in one place, which is useful until that place becomes the outage.
Compare trust boundaries, then test the path
A hub that terminates tunnels can read the traffic it routes. A relay may carry an independently protected exchange when the application encrypts end to end, and a broker usually terminates the session it presents. Establish where protection actually ends before deciding that two designs are equivalent because both are encrypted.
Then check what the workstation can actually reach outbound, since every design above depends on it. Run this on the workstation, substituting the hostname you intend to use.
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comAccept the design only after the intended remote operation succeeds under the permitted identity, an unapproved identity is refused, and the behaviour when the direct or relayed path is unavailable is known and documented. Include a reconnect and the workstation's normal startup context, because a session that began in the office over the LAN tests nothing that remote access depends on.