Part 4: SSH Tunnels Deep Dive - SSH as a SOCKS Proxy
By this point, we’ve already seen how SSH can forward traffic to a specific port or even through another internal host. Let’s now look at the last type of SSH tunnel: dynamic port forwarding. Dynamic forwarding builds on those ideas, but removes the need to decide the destination upfront.
Instead of forwarding one specific port to one specific service, dynamic port forwarding turns SSH into a local proxy that can carry any TCP traffic through the connection. Because of this flexibility, an SSH session using dynamic forwarding can behave almost like a lightweight, application-level VPN.
The idea is simple: SSH opens a SOCKS5 proxy on your machine. Any application that knows how to use a SOCKS proxy, web browsers, package managers, command-line tools, can send their traffic into it. SSH then decides where that traffic should go based on the requests coming from the application. It’s the application, not the tunnel, that chooses the final destination.
You will often see dynamic port forwarding used for web browsing. By routing your browser’s traffic through an SSH tunnel, you can make it appear as if you’re browsing from the SSH server’s network. This is useful for accessing geo-restricted content, bypassing local network filters, or simply adding an extra layer of encryption to your web traffic.
To see this behavior clearly, we’ll recreate a situation where normal internet access is blocked and then use dynamic forwarding to work around it.
Lab Setup
For this scenario, we can reuse our local ssh tunnel lab setup, so we have:
The client machine (192.168.60.10) where I’ll run my SSH command and open the tunnel.
The webserver server (192.168.60.11 ) that I can connect to via SSH.
Instead of keeping this abstract, the diagram below shows how dynamic port forwarding works end to end, from the local SOCKS proxy to the SSH server and out to the destination requested by the application.
NOTE:
If you skipped the first part or haven’t set up the lab yet, the GitHub repository includes the full setup so you can start from here.
Simulating a Network Restriction
But first let’s do some house cleaning and disable the firewall on the webserver so that we don’t have any issues when testing the dynamic tunnel.
This ensures that any failure we see comes from the client side restrictions, not from the SSH server itself. So, on the webserver run:
$ sudo ufw disable
With the server ready, we can now introduce the real problem dynamic forwarding is meant to solve.
Now let’s pretend that our ISP is blocking access us from accessing websites, so if we try to curl google.com from the client machine, it will fail, to simulate that, we can configure a firewall to block all outgoing http and https traffic on the client machine:
