Port forwarding

Port forwarding involves sending connection requests to a different port than requested, a different system than requested or both. For example, you might request a connection to port 23 on a system, but find that your connection is sent to port 2323 instead, to port 23 on a remote server or to port 2323 on a remote server.

There are several reasons why people forward ports and several ways to effect the forwarding. For some sites, ports are forwarded by local systems when the intended targets are otherwise unreachable. For others, ports might be forwarded via secure tunnels as a way to secure their content.

Port forwarding is commonly used to provide users with access to systems they cannot normally reach. If only one system on your network is allowed to make telnet connections to external systems, you might want to forward your telnet requests to that system.

Port forwarding can be thought of as a combination of routing and packet rewriting. After all, to work, port forwarding needs to adjust either the destination IP, target port or both in packets to get them to the intended network services. At the same time, the forwarding has to be transparent as far as users are concerned. They might be completely unaware that their connections are being made to a system other than the one that they are addressing explicitly. In any case, the port forwarding also needs to work in both directions. If you think you’re connecting to port 23 and you’re really connecting to port 2323, the connection must still look like it’s coming from port 23 at your end.

Port forwarding can be done on a firewall, through the use of software such as ssh or via some script or program you download or write yourself.

Forwarding ports via ssh is fairly straightforward and adds the benefit of encryption. A command such as the one shown below, for example, will send connections arriving on port 2323 to port 23 on the system called “remhost”. This command actually establishes a tunnel. You will be prompted to log in on the remote system and, while the connection remains established, you and others can make use of it.

locahost# ssh -L 2323:localhost:23 remhost

If someone already logged into the local system issues a “telnet localhost 2323” command, they will end up logging into remhost. The benefit is that, because the connection is using ssh, it’s encrypted even though we’re connecting with telnet.

One drawback of ssh port forwarding is that these connections can only be used when you’re logged into the system on which the tunnel was established. As you can tell from this netstat output, the tunnel only listens on the local system for requests.

lochost:/ # netstat -an | grep 2323
127.0.0.1.2323             *.*              0    0 49152    0 LISTEN
127.0.0.1.64384      127.0.0.1.2323     49152    0 49152    0 ESTABLISHED
127.0.0.1.2323       127.0.0.1.64384    49152    0 49152    0 ESTABLISHED
127.0.0.1.64386      127.0.0.1.2323     49152    0 49152    0 ESTABLISHED
127.0.0.1.2323       127.0.0.1.64386    49152    0 49152    0 ESTABLISHED
127.0.0.1.2323       127.0.0.1.64319    49152    0 49152    0 TIME_WAIT

In the netstat output shown, we see the LISTEN associated with the operational tunnel, a TIME_WAIT associated with a recent connection over the tunnel and two current (bidirectional) sessions. In other words, we have the tunnel itself, established with the ssh command shown above, two current users and one session which was recently closed.

Port forwarding only requires root access if you are establishing a tunnel on ports lower than 1024 (i.e., less than or equal to 1023). These are, of course, “privileged” ports. Any user could have issued the “ssh -L 2323” command and created the tunnel since this port is well above the privileged range.