•Click the ‘Add’ button. Your forwarding details should appear in the list box.
To remove a port forwarding, simply select its details in the list box, and click the ‘Remove’ button.
In the ‘Source port’ box, you can also optionally enter an IP address to listen on, by specifying (for instance) 127.0.0.5:79. See
section 3.5
for more information on how this works and its restrictions.
In place of port numbers, you can enter service names, if they are known to the local system. For instance, in the ‘Destination’ box, you could enter popserver.example.com:pop3.
You can modify the currently active set of port forwardings in mid-session using ‘Change Settings’ (see
section 3.1.3.4
). If you
delete a local or dynamic port forwarding in mid-session, PuTTY will stop listening for connections on that port, so it can be re-used by another program. If you delete a remote port forwarding, note that:
•The SSH-1 protocol contains no mechanism for asking the server to stop listening on a remote port.
•The SSH-2 protocol does contain such a mechanism, but not all SSH servers support it. (In particular, OpenSSH does not support it in any version earlier than 3.9.)
If you ask to delete a remote port forwarding and PuTTY cannot make the server actually stop listening on the port, it will instead just start refusing incoming connections on that port. Therefore, although the port cannot be reused by another program, you can at least be reasonably sure that server-side programs can no longer access the service at your end of the port forwarding.
If you delete a forwarding, any existing connections established using that forwarding remain open. Similarly, changes to global settings such as ‘Local ports accept connections from other hosts’ only take effect on new forwardings.
If the connection you are forwarding over SSH is itself a second SSH connection made by another copy of PuTTY, you might find the ‘logical host name’ configuration option useful to warn PuTTY of which host key it should be expecting. See
section 4.13.5
for details
of this.
•
4.25.1 Controlling the visibility of forwarded ports
•
4.25.2 Selecting Internet protocol version for forwarded ports
4.25.1 Controlling the visibility of forwarded ports
The source port for a forwarded connection usually does not accept connections from any machine except the SSH client or server machine itself (for local and remote forwardings respectively). There are controls in the Tunnels panel to change this:
•The ‘Local ports accept connections from other hosts’ option allows you to set up local-to-remote port forwardings in such a way that machines other than your client PC can connect to the forwarded port. (This also applies to dynamic SOCKS forwarding.)
•The ‘Remote ports do the same’ option does the same thing for remote-to-local port forwardings (so that machines other than the SSH server machine can connect to the forwarded port.) Note that this feature is only available in the SSH-2 protocol, and not all SSH-2 servers support it (OpenSSH 3.0 does not, for example).
4.25.2 Selecting Internet protocol version for forwarded ports
This switch allows you to select a specific Internet protocol (IPv4 or IPv6) for the local end of a forwarded port. By default, it is set on ‘Auto’, which means that:
•for a local-to-remote port forwarding, PuTTY will listen for incoming connections in both IPv4 and (if available) IPv6
•for a remote-to-local port forwarding, PuTTY will choose a sensible protocol for the outgoing connection.
This overrides the general Internet protocol version preference on the Connection panel (see
section 4.13.4
).
Note that some operating systems may listen for incoming connections in IPv4 even if you specifically asked for IPv6, because their IPv4 and IPv6 protocol stacks are linked together. Apparently Linux does this, and Windows does not. So if you're running PuTTY on Windows and you tick ‘IPv6’ for a local or dynamic port forwarding, it will only be usable by connecting to it using IPv6; whereas if you do the same on Linux, you can also use it with IPv4. However, ticking ‘Auto’ should always give you a port which you can connect to using either protocol.