SSH Port Forwarding
If you are an engineer who works closely with IT infrastructure, port forwarding might not be new to you. You may be doing this in your daily routine, but perhaps without having a proper understanding of its internals, and why its applicable to your work.
Before we get into the topic, let’s look at a few port forwarding scenarios.
Scenario 1
There is a computer in a remote location, but it belongs to a private network (see Figure 1). However, the user needs to get access to the remote terminal to operate that computer. It’s not possible, right?
If the remote computer can create a socket connection to a public server, where transmitting commands from the latter to the former’s shell is possible, the user will be able to operate it almost like he is sitting in front of that computer.
Scenario 2
There is a service running in port 80 of a server that is behind a firewall (see Figure 2). Since inbound traffic is banned beyond the firewall, the external user is not allowed to access the service.
So, how would the user access this service?
If the service can forward its traffic to a port of another server that is accessible by an external user, then the user can use the service, like exposed through the latter server.
Scenario 3
A user needs to access the GUI of a remote terminal with VNC (https://www.realvnc.com/en/). To do that the user’s VNC client should be capable of connecting with the remote terminal’s VNC server through the port 5901 (default VNC server port).
What if there’s a firewall in front of a remote machine that prohibits all traffic to port 5901?. Yes, in this scenario, it’s not possible to access the remote terminal (see Figure 3).
However, let’s say the firewall allows traffic from a particular port (in this case, port 22). If a SSH tunnel* can be created from the user’s terminal to the remote terminal, then the VNC client is capable of using that tunnel to connect with the remote VNC server.
*SSH tunnel is a SSH connection to the remote terminal through an allowed port.
The three scenarios which have been described are representations that can be solved using SSH Port Forwarding.
Let’s discuss SSH Port Forwarding concepts in detail, and then look back on how the above scenarios were solved through them.
SSH Local Port Forwarding
Let’s assume that there is an application server which runs on port 143 of the remote machine (Host D). Due to some restrictions, the application client (Host C) on the local side cannot connect directly with that application server in Host D.
However, if a particular port like 22 is not restricted, SSH has the capability of creating an SSH connection from the local computer to the remote computer and forward any local port traffic to a given port on the remote side.
As shown in figure 5, the traffic in port 2001 (Host A), where the application client (Host C) is pinned into, can be forwarded to port 143 of Host D via Host B by using Local Port Forwarding. The user can use the following command in Host A for this.
ssh -g -L 2001:HostD:143 user@HostB
Once you execute the above command in Host A the SSH Client will forward the port 2001 traffic into the SSH server (SSHD server in normal terms) of Host B, which extends that traffic with port 143 of Host D.
Now the user can access the application server through the application client almost like its directly connected with the application server.
SSH Remote Port Forwarding
Suppose there is an application server that runs on port 143 of the local machine. Due to some restrictions, the application client on the remote side cannot connect directly with that application server.
SSH has the capability of creating a SSH connection from the local computer to the remote computer and let any remote port traffic be forwarded to a given port on the local side.
As shown in figure 6, the traffic in port 2001, where the application client is pinned into, can be forwarded to the port 143 through Remote Port Forwarding. The user can use the following command for this.
ssh -R 2001:localhost:143 user@HostB
Now the remote user can access the application server through the application client almost like its directly connected with the application server.
Lets revisit the afore mentioned scenarios
Scenario 1
In this scenario, since the user can’t reach the computer in a private network, the user can ask it to make a remote forwarding (like below) (this is a one-time establishment)
ssh –R 38567:localhost:22 user@publicServer
This means
Create a SSH tunnel with the public sever and let the public server forward traffic of port 38567 to port 22.
All right! Now the shell of the computer in a private network is accessible through the port 38567 of the public server.
Scenario 2
In this scenario, since the user is not allowed to access port 80 of the remote server, he can ask it to make a remote forwarding (like below) (this is a one-time establishment)
ssh -R 8080:localhost:80 user@host
This means
Create as SSH tunnel with the host sever (which is accessible to the user) and let the host server forward traffic of port 8080 to its port 80
All right! Now the user can access the remote server which he isn’t allowed to access via port 8080 of the host server.
Scenario 3
In this scenario, since the user can’t reach the remote computer’s VNC server through port 5901, he can make a local forwarding (like below) (Here it is assumed that port 22 is allowed as inbound traffic of the remote terminal)
ssh -L 4567:localhost:5901 user@remoteTerminal
This means
Create a SSH tunnel with the remote computer and forward the traffic of port 4567 to port 5901 of the remote computer.
All right! Now the user can connect with the remote terminal’s VNC server without any issue, although 5901 is not allowed.
Final Words:
Before reading this article, you may or may not have heard about SSH Tunneling. Maybe you’ve used this without a proper understanding of the underlying concepts. No matter which category you belong to, I believe you have gotten a sufficient direction from this article.
