SSH Port Forwarding: Local, Remote, and Dynamic Tunnels

SSH port forwarding routes network traffic through an encrypted SSH connection. Developers use it to reach private services, expose a local app through a server, or create a SOCKS proxy without adding a separate VPN.

The mechanics are worth learning because many tunnel products borrow the same mental model. The tradeoff: SSH gives you transport, while review sessions need access control, expiry, and request visibility.

SSH port forwarding modes

OpenSSH supports three common forwarding modes: local, remote, and dynamic. The flags are -L, -R, and -D.

OpenSSH also supports -N, which tells SSH not to run a remote command. That fits forwarding sessions because you want the tunnel, not a shell.

Local port forwarding with -L

Local port forwarding listens on your machine and sends matching traffic through the SSH connection to a destination reachable from the remote host.

ssh -N -L 15432:127.0.0.1:5432 user@bastion.example.com

This command opens localhost:15432 on your machine. Traffic to that local port crosses the SSH connection to bastion.example.com, then connects from the remote side to 127.0.0.1:5432.

Use this when you need your laptop to reach something behind an SSH-accessible server. It works well for internal databases, dashboards, and admin services. It does not create a browser link for a client. The public surface still sits on your machine, and only you can connect to the local forwarded port unless you change bind behavior.

OpenSSH lets you bind to specific addresses. Treat that with care. Binding a forwarded port to all interfaces can expose the local listener to your network.

Remote forwarding with -R

Remote forwarding does the reverse. It opens a listener on the SSH server and forwards incoming connections back to your local machine.

ssh -N -R 8080:127.0.0.1:3000 user@vps.example.com

This can let someone reach your local dev server through vps.example.com:8080, depending on SSH server configuration and firewall rules. The server may bind remote forwarded ports only to loopback by default. Public binding often requires GatewayPorts in sshd_config, plus a firewall rule or reverse proxy.

That makes remote forwarding useful and demanding. You need a VPS or SSH server, SSH keys, server config, a public DNS or address, and cleanup after the session. You also need logging if you want to know who connected and which requests failed.

For a non-technical reviewer, a bare host:port can also feel less polished than a short HTTPS browser link.

Dynamic forwarding with -D

Dynamic forwarding turns SSH into a local SOCKS proxy.

ssh -N -D 1080 user@bastion.example.com

Your browser or CLI tool can use localhost:1080 as a SOCKS proxy. SSH decides the destination per connection. This helps when you want to browse as if you were on the remote network.

Dynamic forwarding is not a localhost sharing tool. It gives you a proxy for your traffic. It does not give a reviewer a URL to your local app.

SSH tunnel tradeoffs for developer review

SSH tunnels remain useful because they use a tool many developers already trust. They also expose how much work hides inside a polished sharing workflow.

For client or stakeholder review, SSH port forwarding has gaps:

• You need a reachable SSH server.
• You manage keys, host verification, and server config.
• Remote forwarding may need GatewayPorts and firewall changes.
• There is no built-in TTL for a review window.
• There is no default viewer list or request failure surface.
• Reviewers may need an awkward hostname and port instead of a clean HTTPS URL.

wiremaven wraps the “public route to local port” job around a review session. It creates temporary encrypted public links for local dev servers. Your machine opens an outbound-only WebSocket relay. The reviewer gets a browser link. You see viewer, request, and failure signals. You can choose 15, 30, or 60 minute TTLs. During beta, no account is required.

npx wiremaven-cli 3000 --expires 30m --name ssh-alternative

Use SSH when you need network plumbing and control. Use wiremaven when you need a local build review with less server work.

Security checklist

Before you use SSH forwarding, check the basics.

• Use key-based authentication and protect private keys.
• Verify host keys for new servers.
• Avoid binding forwarded ports to all interfaces unless you mean to.
• Close forwarding sessions after use.
• Confirm server firewall rules match the access you intend.
• Do not expose admin panels or databases for reviewer convenience.

For wiremaven’s relay model, read how wiremaven works. For CLI and framework setup, see the docs.

FAQ

What is SSH port forwarding?

SSH port forwarding sends traffic through an encrypted SSH connection. It can create local listeners, remote listeners, or a SOCKS proxy.

What is local port forwarding?

Local port forwarding uses ssh -L to open a port on your machine and route it through an SSH server to a remote destination.

What is remote SSH forwarding?

Remote forwarding uses ssh -R to open a port on the SSH server and route traffic back to a service reachable from your local machine.

Is SSH port forwarding good for client demos?

It can work if you already have a server and know the config. A review-focused tunnel gives reviewers a browser link and gives you session signals with less setup.

Start from the review goal

If you want to learn networking, practice -L, -R, and -D. If you need to send a local app to a reviewer, start with a short-lived link.

npx wiremaven-cli 3000 --expires 30m

Related: What Is a Localhost Tunnel? | How to Share Localhost with a Client | Tailscale Funnel: Setup, Use Cases, and Alternatives