Inside Port4WRD: Multiplexed tunnels without router port forwarding

Building a tunnel looks simple from the outside: accept traffic on a public address and send it to a service running on a private machine. The difficult part starts after the first successful request. A useful tunnel has to survive disconnections, keep unrelated services isolated, release capacity after failures, and make its security boundary clear to the operator.

This field note explains the design decisions behind Port4WRD.link, the tunneling platform I am building for HTTP, HTTPS, and TCP workloads. It focuses on the architecture and failure cases rather than the marketing promise.

The problem is not only router configuration

A development server normally listens on an address such as 127.0.0.1:3000. That is appropriate for local work, but an external webhook provider, teammate, or test device cannot reach it.

Traditional inbound port forwarding can solve that problem when the operator controls the router and has a reachable public address. It becomes less practical when the network uses carrier-grade NAT, when router access is unavailable, or when a public IP changes. Opening an inbound port also moves security work to every network where the application is run.

Port4WRD reverses the direction of the initial connection. The client initiates an outbound session to the relay, authenticates, and asks for one or more public routes. Because the long-lived connection begins inside the private network, the operator does not need to create an inbound router rule for each local service.

The simplified path is:

Public client
    ↓
Port4WRD relay and route
    ↓
Outbound tunnel session
    ↓
Port4WRD client
    ↓
Local HTTP or TCP service

That diagram is the easy part. The rest of the design is about keeping the path predictable.

One session, multiple logical streams

Opening a new transport connection for every forwarded request would add setup cost and make connection management harder. Port4WRD instead uses a long-lived TLS session and multiplexes independent logical streams over it.

Multiplexing matters because the client may expose several services and each service may handle concurrent connections. A slow stream should not require a completely separate control connection, and creating one tunnel should not force the client to repeat authentication for every request.

The control plane and data plane still have different responsibilities:

• The control path authenticates the client, creates or removes routes, and reports lifecycle events.
• The data path carries the bytes for each HTTP, HTTPS, or raw TCP connection.
• Stream boundaries prevent bytes from one forwarded connection from being mixed with another.
• The relay remains responsible for mapping a public route to the correct authenticated client session.

This separation also makes failures easier to reason about. A single stream can end without necessarily ending the whole client session. If the underlying session disappears, every route attached to it can be cleaned up together.

HTTP routes and TCP routes are not interchangeable

HTTP forwarding has information that a raw TCP listener does not: hostnames, methods, headers, paths, and status codes. That enables domain-based routing and useful request-level diagnostics.

TCP forwarding must remain protocol-agnostic. The tunnel cannot assume that the payload is HTTP, text, or even request-response traffic. It should move bytes in both directions and close both sides cleanly when either endpoint finishes.

Treating these as separate route types avoids misleading behavior. An HTTP route can provide a public hostname suitable for a local web server or webhook receiver. A TCP route reserves a public listener and forwards the accepted connection to the selected local port. The shared tunnel transport does not mean the public protocols have identical lifecycle rules.

Capacity must be owned by one authority

A tunnel limit is easy to implement incorrectly. If each client process counts only its own active tunnels, the same account can start several clients and exceed the intended limit. Concurrent requests can also pass a check at the same time and reserve more capacity than expected.

The current Port4WRD design treats tunnel slots as an account-wide reservation managed by the portal. A client requests a slot before starting a tunnel, and the portal is the authority for the account's active allocation. The current limit is 25 slots per account.

The important part is not the number 25. It is the lifecycle around the reservation:

1. Reserve a slot before allocating the public route.
2. Start the tunnel only after the reservation succeeds.
3. Release the reservation if route creation fails.
4. Release it again when the tunnel stops normally.
5. Reconcile stale reservations after abnormal disconnects.

Failure cleanup has to be idempotent. A repeated release should not reduce the count twice, and a failed start must not leave a ghost reservation that blocks a later tunnel.

Reconnection is a state transition, not a loop with no limits

Network interruptions are expected on laptops, mobile connections, and development machines that sleep. Immediate reconnect attempts can make an outage worse by creating a tight retry loop across many clients.

The client uses bounded reconnection behavior with increasing backoff. A reconnect has to restore more than the socket: it must re-authenticate, re-establish its session, and recreate the routes that are still supposed to be active. Until that succeeds, the UI and logs should describe the tunnel as disconnected rather than pretending the previous public route is healthy.

Graceful shutdown is the other half of recovery. The client stops accepting new work, closes active streams, releases reservations, and tears down the session in a defined order. Timeouts keep a stalled peer from holding the process open forever.

Resource controls protect the client as well as the relay

A public endpoint can receive traffic the developer did not expect. Even during testing, the client needs limits around concurrent connections, idle time, buffer use, and diagnostic capture.

The implementation therefore treats these as operational controls rather than later optimizations:

• Connection limits prevent unbounded local fan-out.
• Read and write deadlines keep abandoned connections from living forever.
• Reused buffers reduce allocation pressure without sharing payloads between streams.
• Request or response capture is size-limited so diagnostics do not become an accidental memory sink.
• Cleanup paths close both the public and local side of a forwarded connection.

These controls cannot make an unsafe local application safe, but they can keep the forwarding layer from magnifying a small failure.

A tunnel is connectivity, not authorization

This is the most important operating boundary: a public tunnel exposes whatever the local service permits. Port4WRD does not replace authentication inside the application.

Before exposing a service, I use the following checklist:

• Bind only the intended local service and port.
• Keep application authentication enabled.
• Avoid exposing database ports, container APIs, or private admin panels to the public internet.
• Use short-lived tunnels for previews and webhook tests when a permanent route is unnecessary.
• Rotate a tunnel credential if it may have been copied into logs or shared outside the intended team.
• Review route and connection activity instead of assuming an obscure URL is private.

The secure default is still to expose the smallest possible surface for the shortest useful time.

What this architecture taught me

The hardest tunneling bugs have not been about copying bytes. They have been ownership bugs: which component owns a route, which system owns the account limit, and which cleanup path runs after a partial failure.

Three design rules have been especially useful:

1. Keep one authority for shared state. Account-wide capacity cannot be derived reliably from one client process.
2. Model failure explicitly. Starting, connected, reconnecting, stopping, and failed are different states with different cleanup duties.
3. Do not blur the security boundary. The tunnel provides reachability; the application remains responsible for access control and the operator remains responsible for deciding what to expose.

Port4WRD began as a way to reach a local service without changing a router. Building it into a dependable platform requires much more: multiplexed transport, authoritative reservations, bounded retries, resource controls, and honest operational state. Those less visible parts are what make the public URL useful after the demo is over.