Using SSH Reverse Tunneling to Access Internal Web Servers from Headquarters

The author, a senior architect, presents a scenario where the headquarters needs to access a web server inside a branch office, but the DMZ can only reach external port 22 and the web server cannot access the public network while it can reach the DMZ.

Recognizing that network communication is bidirectional, the reply channel is used for reverse access by establishing an SSH tunnel that forwards traffic from the headquarters back to the internal web server.

On the DMZ host the following command creates a reverse tunnel listening on port 6606 of the headquarters and forwarding it to the web server’s port 80:

ssh -f -N -g -R 6606:10.1.1.1:80 [email protected]

The flags mean: -f runs the process in the background, -N disables remote command execution, -g listens on all local interfaces, and -R sets up remote port forwarding.

Verification on the headquarters server shows the tunnel is active:

netstat -tunlp | grep 6606

Attempting to connect to the forwarded port initially fails because the web server side is not yet listening:

telnet 127.0.0.1 6606 → connection refused.

Next, a reverse tunnel is created from the web server back to the DMZ, exposing the web server’s port 80:

ssh -f -N -g -R 80:10.1.1.1:80 [email protected]

After this step, testing the forwarded port from the headquarters succeeds:

telnet 127.0.0.1 6606 → connected.

Further inspection with ss | grep 6606 confirms a bidirectional ESTABLISHED TCP connection between 127.0.0.1:6606 and the remote endpoint, and netstat shows the listening process (PID 8616) on the headquarters.

The article concludes that by leveraging the SSH reverse tunnel’s encrypted return channel, the headquarters can transparently access the internal web server without altering existing network policies, effectively establishing a two‑way communication path.