SSH Remote Tunneling

Last time we introduced local port forwarding with SSH. Today let's look at related features: remote port forwarding and socks proxying.

Remote port forwarding

Remote port forwarding works exactly like local forwarding, but the other way around: while local forwarding transfers local connections to the remote machine, remote forwarding transfers remote connections to you (or another machine you have access to).

When is this useful? Well most of the time, your network setup is such that you can access the server through SSH, because it has a public IP address, but the server can't access you because you are behind a firewall or a router.

So an example use case would be remote debugging an application. A debugger is installed on a remote development server, but the debugger can't reach you, and therefore your IDE/editor of choice. You thus setup things as follow:

Set the debugger on the server to connect to localhost (default)
Forward the remote port (9000) to your machine (same port)
Set your IDE on listen mode, ie listening for debugger connections
Start a debugging session

The SSH command is :

ssh -R 9000:127.0.0.1:9000 example.com

And the scenario:

http://example.com?START_DEBUG=1 ----+
                                     |
+-- SSH <- server:9000 <- debugger <-+
|
+-> SSH -> local:9000 -> IDE

Apart from the direction of the forwarding, it works exactly like local forward, and thus offers the same options: you bind to localhost, an external address, or all interfaces, and you can forward to a local port, or to another machine you have access to.

In a complex scenario, you could have something like this: a remote server B talks to a webservice on server A (also remote), but A doesn't have a webservice. The webservice is on your network, so you use your machine and machine A as bridges to make everybody communicate:

webservice <---------> you <----> A <---------> B
            network 1       SSH      network 2

with:

ssh -R 9000:webservice:9000 machine-a

That's it for local and remote port forwarding. Sometimes however, you need a little more than one or two ports, and you need to redirect a large part of your connections through a 3rd party: this is what SOCKS is for.

SOCKS Proxying

SOCKS is a protocol specifically designed to proxy network connections. It works by setting up a server which acts as a gateway/proxy to all connections. SOCKS aware applications can connect to it, send their packets, and the SOCKS server will take care of sending them to their destination.

As a general proxying mechanism, SOCKS is much more powerful than simple port forwarding. Through one single SOCKS server, you can proxy multiple applications and protocols, as long as they support SOCKS, which many applications do. Most web browsers and instant messengers for example natively support it.

So how is that related to SSH and how do you use it? Well SSH can act as a SOCKS server. It is as simple as:

ssh -D 7000 example.com

and you have a SOCKS server running on port 7000 of your machine, proxying all client connections through example.com. Now all you have to do is configure your applications to use the SOCKS server.

Configuration: Mac OS X

If your computer is running on Mac OS X, setting up a SOCKS proxy for all your applications can easily be done in one place. You need to go to your Network Preferences:

Select the Advanced button for your connection:

Click the SOCKS Proxy option and fill out the parameters:

You're done. All the applications on your Mac will now use this configuration (at least those who do it right, which is most).

Configuration: Firefox

If your operating system doesn't provide such configuration, you can generally configure it on a per-application basis. With Firefox, go to Preferences -> Advanced -> Network and click on Settings

There you can fill out the SOCKS proxy information:

Other browsers have similar configuration screens. If you are gonna switch between proxy and no proxy pretty often, it might be useful to add a plugin/extension to your browser to be able to switch easily without having to go through all these configuration screens all the time :

QuickProxy and FoxyProxy for Firefox
Proxy Switchy! for Chrome

Final note: DNS

The SOCKS protocol was built to proxy any kind of network connection through a server. When you enable a SOCKS proxy in some browsers however, there is one type of connection that doesn't get proxied: DNS.

When you request a web page at http://example.com, the browser will first ask the operating system to resolve example.com to a known IP address, and then go through the SOCKS proxy to connect to that IP. What this mean is that if you are using a proxy for privacy reasons, you are leaking information to the DNS resolver. Depending on your situation, that may or may not be an issue, but it's good to be aware of it. If you want to have full privacy, you need to go through an HTTP proxy instead, because in this case the HTTP proxy is in charge of the DNS resolution, not you (which of course only works if you are in control of the HTTP proxy, otherwise you just moved the problem somewhere else). Or you can just change the default setting.

Conclusion

That's it for today. Hope you enjoyed it.

Until next time, Cheers!