Port Forwarding

Tunnel TCP ports over an SSH host — reach a database only the server can see, or publish a local service on the remote side.

The three kinds

Local — open a port on this machine; connections are carried to the SSH host, which dials the destination. Reach a database that only the server can see: listen on 127.0.0.1:5432, destination db.internal:5432.

Remote — open a port on the SSH host; connections there come back to you. Show a colleague a service running on your laptop: bind 0.0.0.0:8080 on the host, destination 127.0.0.1:3000.

Dynamic — open a SOCKS5 proxy on this machine; the client names a destination per connection. Point a browser at 127.0.0.1:1080 and browse as though you were on the server's network.

Where the destination is resolved

For a local or dynamic rule the destination is resolved by the SSH host, not by you — which is exactly what makes it useful for names that only exist over there. For a remote rule it is the other way round: the destination is resolved from this machine.

What is and isn't encrypted

The hop between you and the SSH host is encrypted. The final hop is plain TCP — the SSH host terminates the encryption and dials the destination in the clear.

The diagram on each rule draws this: a solid, locked segment for the SSH connection and a dashed one for the onward hop. If the last leg crosses a network you don't trust, the tunnel is not what protects it.

Create a rule

1. Port Forwarding → New rule.
2. Pick the direction, and the SSH host the tunnel rides.
3. Set the local bind address and port, and the destination host and port.
4. Start.

Rules are saved but do nothing until started. A running tunnel keeps going when you close the tab or navigate away — it belongs to the app, not the page.

Binding beyond localhost

127.0.0.1 keeps a tunnel private to this machine. 0.0.0.0 exposes it to anything that can reach the machine holding it, and rules bound that way are badged Exposed. Use it deliberately.

With a jump chain

If the SSH host is reached through bastions, the tunnel follows that route automatically — the hops carry SSH inside SSH, and only the last link is plain TCP.

When it doesn't work

• "Port … is already in use" — something else is on that local port. Stop it or pick another.
• Ports below 1024 need elevated privileges; pick a higher one.
• "has not been accepted yet" — tunnels verify host keys strictly and never prompt. Open a terminal to that host once and confirm its fingerprint.
• The server refused to listen (remote rules) — the port may be taken there, or the server disallows it. AllowTcpForwarding and GatewayPorts control this in sshd_config.
• The bound port differs from the one you asked for — a server may choose its own; the card reports the port actually bound. Connect to that one.

Tips

• The card shows live throughput and open streams, so you can tell "bound but idle" from "carrying traffic".
• A dynamic rule lists the destinations it is currently reaching.