PuTTY local vs remote port forwarding: which default limits accidental public exposure?

Answering the Core Question First

In practice, local forwarding is the safer default. It binds to a port on the client machine, and unless you explicitly tell PuTTY otherwise, that port is only reachable from the client itself. Remote forwarding, on the other hand, asks the jump host to open a listening socket. Whether that socket is exposed to the rest of the world depends on the server’s GatewayPorts setting and on how you specify the source port in PuTTY.

Local Forwarding

• PuTTY’s local‑forward dialog accepts a source port like 5000 or localhost:5000.
• Without the localhost: prefix, PuTTY tells the OS to listen on all interfaces (0.0.0.0). That can make the forwarded service reachable from other machines on the client’s network.
• Adding localhost: forces the bind to 127.0.0.1, which is invisible to the outside world.

Remote Forwarding

• The source port field works the same way: 6000 or localhost:6000.
• PuTTY itself does not enforce any binding rules on the server; it simply requests that the server open a listening socket.
• Whether that socket is reachable depends on sshd_config:
  • GatewayPorts no – the server will only bind to 127.0.0.1, regardless of what PuTTY asked for.
  • GatewayPorts clientspecified – the server respects the client’s source‑port prefix. If you specify localhost:, the socket stays local; if you omit it, the socket is bound to 0.0.0.0.
  • GatewayPorts yes – the server ignores the client’s prefix and always binds to 0.0.0.0, making the forwarded service publicly reachable.

PuTTY’s Error Reporting for Disabled Forwarding

If the server’s AllowTcpForwarding no, PuTTY will not silently drop the request. Instead, the SSH session will terminate the forward attempt and display an explicit error such as:

Server refused to set up TCP/IP forwarding

So you can rely on PuTTY to surface the problem rather than fail silently.

No Global Loopback‑Only Setting in PuTTY

PuTTY provides no single checkbox that forces all forwards to bind to loopback. Each tunnel must be configured individually with the localhost: prefix. Verification is still required:

• For local forwards – run netstat -ano | findstr 5000 on the Windows client and confirm the address is 127.0.0.1:5000.
• For remote forwards – check ss -ltnp | grep 6000 on the jump host to see the bound address.

Bottom Line

Choose local forwarding if you want the most predictable isolation. Remote forwarding can be equally contained, but only if the server’s GatewayPorts setting is no or clientspecified and you use the localhost: prefix. PuTTY will alert you if the server refuses forwarding, and there is no client‑side toggle that guarantees loopback binding – you must set it per tunnel and verify on the client or server.