Why Your VPN Tunnel Address Does Not Open an Inbound Port
A tunnel address identifies your client to peers that can route to it, and never creates a listener. Check the bind, the return route, then policy.
Connect to the office VPN, start a small service on port 8443, send the tunnel address to a colleague, and watch the connection fail while the client still reports connected. Nothing is broken in the tunnel: the address was handed out, the session is up, and the packets that would carry the answer are simply never admitted. Work the three checks below in order and stop at the one that fails, because each has a different fix and only one of them is about the VPN.
Begin with where the socket is actually bound
Before anything routes, something has to be listening on an address the caller can reach. Development servers are the usual offender, since many of them bind to loopback by default and accept only connections that originate on the same machine. A tunnel address does not change that binding, and the operating system will refuse the connection long before the VPN is involved.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Read the local address column rather than the state. 127.0.0.1:8443 means loopback only, and the fix is a bind on 0.0.0.0 or on the tunnel address itself. 0.0.0.0:8443 accepts on every interface, which is broader than most people intend when the machine also has a public address; 10.64.7.15:8443 is the narrow version that listens only where the colleague can reach it. Note the process name in the same output, because a stray instance from an earlier test is a common reason the port looks open and answers with the wrong content.
Then ask whether anything can route to that address
A tunnel address is meaningful only to peers configured to send that prefix into the tunnel. The colleague's machine has its own table, and unless it has a route for the tunnel subnet, the packet goes to the default gateway and dies in a place that has no idea the address exists. That is a routing question on the caller's side, not a permission on yours.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
The server between the two clients matters just as much. In the common remote-access design, each client opens an outbound connection to the gateway and the gateway keeps state for those flows, so replies come back on a path it already knows. A connection from one client to another is a new flow that the gateway has to accept and forward, and many deployments disable that deliberately to keep clients isolated from each other. Consumer VPN services usually isolate by default; corporate gateways sometimes allow it per group.
Check the direction before you change anything on the host. If the tunnel address answers from the gateway itself but not from a peer, the gateway's client-to-client setting is the difference, and no amount of local firewall editing will substitute for it.
Finally, find the policy that permits the flow
Three policy layers sit between a routed packet and a service that answers: the VPN server's forwarding decision, the host firewall, and any cloud security group in front of the instance. All three have to agree, and they fail in different ways, which is why the symptom in the table above is more useful than the error message in the browser.
The host firewall is the layer people forget after a successful bind, because a rule that allows the port on the LAN interface does not automatically allow it on the tunnel interface. Interface-scoped rules are correct design and are also the usual cause of a service that works from the office and not from home. Read the rule's scope rather than its port number.
Stateful filtering explains the reverse case. An outbound connection from your laptop creates state, and replies to it are admitted without an inbound rule. A colleague's connection is a brand-new flow with no state behind it, so it needs an explicit allowance. That asymmetry is the whole reason a working browser session on your own machine says nothing about whether the service is reachable from outside.
When one check fails, change the design rather than the tunnel
If the requirement is a colleague opening your local service, the honest answer is usually a mechanism built for inbound access. A reverse SSH tunnel is the smallest one: your machine connects out to a host the colleague can already reach, and the listener exists on that host.
ssh -N -R 8443:127.0.0.1:8443 [email protected]The relay needs GatewayPorts clientspecified in its SSH server configuration, otherwise the forwarded listener binds to loopback on the relay and the colleague hits the same refusal as before. For anything longer-lived than an afternoon, a load balancer or ingress with a health check and a certificate for the published name is the better instrument, and a site-to-site tunnel with routes for both subnets is the right answer when two networks genuinely need to talk.
Each of those designs makes the exposure explicit, which is the point. A VPN moves packets between networks you were already authorized to use; it does not publish a service and does not convert a laptop into an internet-facing host. Deciding which of the three layers to change is the task, and the tunnel is rarely one of them.