ゆるテックノート

SSH port forwarding and how it differs from VPNs

SSH port forwarding carries another TCP connection inside an SSH session. It is sometimes used for VPN-like access, but it is best understood as a narrow path to a specific port or application, not as a full network connection.

The basic idea

SSH is commonly used for secure server login, but it can also relay other TCP connections through the encrypted SSH session. This is called SSH port forwarding or an SSH tunnel.

What it can do

  • Reach a private admin page or database from your laptop without exposing it to the internet.
  • Use a bastion host to access a specific service inside a company or cloud network.
  • Wrap traffic in the encrypted SSH path so the local network cannot inspect it directly.
  • Open only the access you need without installing a VPN client.

Common command example

Connecting to `localhost:15432` on your machine reaches `db.internal:5432` as seen from the SSH server.

ssh -L 15432:db.internal:5432 user@example.com

Three forwarding modes

The forwarding mode depends on where the listening port is created and how destinations are chosen.

Mode comparison

Mode Common shape Typical use
Local forwarding (-L) A local port on your machine connects to a destination visible from the SSH server Temporary access to an internal database, admin page, Redis, RDP, or similar service
Remote forwarding (-R) A port on the SSH server connects back to your machine or local network Expose a development environment behind NAT for temporary review or support
Dynamic forwarding (-D) A local SOCKS proxy chooses destinations per connection Send browser or selected app traffic through SSH

How it differs from a VPN

Both VPNs and SSH forwarding can create encrypted tunnels, but they differ in scope and operational model.

Comparison

Point SSH port forwarding VPN
Scope Mostly specific TCP ports or SOCKS-routed traffic Can cover the whole device, selected subnets, or selected apps
Main use Temporary access to specific services for admins and developers Remote work, site-to-site links, always-on access, or consumer privacy support
Traffic support Primarily TCP. UDP and ICMP are not handled directly in the usual setup Depending on the VPN, can operate at IP level and carry TCP, UDP, ICMP, and more
Setup weight Small setup if you already have SSH accounts and keys Needs client, routing, DNS, authentication, and device-management design
Access control Depends heavily on SSH login rights and server configuration Often supports user, device, network, and application-level policy
Audience Usually more technical More suitable for broad user rollout and managed environments

Rule of thumb

  • Use SSH forwarding when you only need one database, admin page, or service.
  • Use a VPN when users need normal access to multiple internal apps or networks.
  • Use dynamic forwarding when a browser or selected app should go through SSH as a SOCKS proxy.
  • For company-wide remote access, evaluate VPN or ZTNA-style products together with authentication, logging, and device checks.

Common examples

SSH forwarding is common for private management services that should not be directly exposed to the internet.

Local forwarding examples

  • Connect a database client to a production database through a bastion host.
  • Open a cloud-internal admin page through `localhost`.
  • Use remote desktop or VNC temporarily without publishing the service port.

Dynamic forwarding example

When using SOCKS forwarding, the browser or app also needs proxy configuration.

ssh -D 1080 user@example.com

Security notes

SSH tunnels are useful, but any forwarded port should be limited to the intended users and destinations.

Practical safeguards

  • Prefer public-key authentication and manage key storage and revocation.
  • Consider server-side controls such as `AllowTcpForwarding` and `PermitOpen`.
  • Binding a local forward to `0.0.0.0` may let other machines on the same network use it.
  • Someone who can log in to the SSH server may be able to create paths into internal services. Bastion host logging and permissions matter.
  • For long-term, many-user, broad access, a VPN or zero-trust access product may be easier to operate.

Takeaway

SSH port forwarding is a lightweight way to pass specific traffic through SSH. A VPN is a broader mechanism for designing device or network routing.

Simple distinction

  • SSH forwarding is a narrow tunnel between specific endpoints.
  • A VPN is a broader tunnel for devices, subnets, or applications.
  • For small administrative access, SSH is often enough; for a remote access platform, VPN is usually the better fit.
  • For VPN visibility and limits, also see what others see when you use a VPN and what VPNs protect and what they do not.