Using SSH, SOCKS, tsocks, and proxy settings to create a simultaneous "dual use" work/home computer

The Problem:

Allow one linux workstation to be simultaneously used for both work and non-work purposes so that work and non-work traffic are segregated.

The Requirements:

I would like to be able to use the following applications in the corporate environment

  1. VNC
  2. Web (typically Google Chrome but potentially other browsers as well)
  3. Email - IMAP, SMTP, LDAP using Thunderbird
  4. IM - pidgin
As already mentioned here the corporate network has an SSH server that you authenticate and connect to and from there you can reach the other corporate network resources.

I would like non-work related traffic to bypass the corporate network - this is mostly web traffic but might also include things like Spotify, yum updates, and other assorted tasks.

Finally it would be nice (but not essential) to wrap all this up in a handy GUI operation or series of operations.

The Environment:

 Fedora Core 16 (x86_64) and Gnome 3.

The Solution:

 Use SSH, SOCKS, tsocks and Gnome 3 proxy settings to sort out the traffic types.

The Implementation:

In short, one uses the -L switch of the ssh command and issues something like 

ssh -L

if the VNC session is hosted on vncserver with display 6, and then the VNC session can be accessed by means of

 vncviewer  localhost:5906

To extend and generalize this technique to allow for web and mail traffic to be forwarded, one has to rely on the -D option for the SSH command. This is a very powerful piece of functionality because it allows the ssh server to act as a SOCKS proxy. This means that applications like web browsers, email clients and more can be pointed to to localhost:1080 (1080 is the port traditionally used for SOCKS) and the SOCKS proxy (on the SSH server) will proxy requests to the needed resources.

So we simply extend our previous SSH command line to

ssh -L -D 1080

and authenticate to the SSH server as before (often with a one-time, generated password).

Now we have to solve the problems of how to point the clients to localhost:1080 and, in the case of web traffic, how to segregate the traffic into work-related and non work-related.

I'll discuss these in reverse order.

Writing and using a Proxy Autoconfiguration File:

The filtering, or traffic segregation, is accomplished by means of Proxy Autoconfiguration file which is actually a piece of javascript code. It's easier to show the actual file than it is to describe what it does. Here is my (very simple) file:

function FindProxyForURL(url, host)

   if (shExpMatch(host, "*"))
         return "SOCKS5 localhost:1080; DIRECT";
      return "DIRECT";

The only thing that seems the least bit tricky here is the use of the SOCKS5 token, as many of the examples that you find on the web use the word PROXY which carries with it a different semantic. 

This file goes in your home directory - I called mine "~/.proxy.pac".

Now, inform the Gnome Shell about this file by going to System Settings | Network Settings | Network Proxy, then choosing "Automatic" as the option, and specifying the autoconfiguration file as a URL, for example "file:///home/someuser/.proxy.pac".

Setting up tsocks:

tsocks is part of the overall solution and we'll need it in the next section so

sudo yum install tsocks

Create a tsocks config file named /etc/tsocks.conf and into it insert these lines

server =
server_type = 5
server_port = 1080 

Configuring the Clients:

Google Chrome is the easiest to configure - you really don't have to do anything - it just respects the Gnome Shell settings. You can now access a corporate resource at

With Firefox we do what we did for Gnome 3 - go to Preferences | Advanced | Settings and enter the URL for "Automatic proxy configuration URL i.e. "file:///home/someuser/.proxy.pac".

For Thunderbird following analogous steps as described for Firefox "works" except for one thing - the IMAP and SMTP ports are forwarded correctly but the LDAP queries (for address autocompletion) don't seem to be. For this reason I went with a tsocks based solution which forwards all ports to the tsocks server including LDAP. So either start Thunderbird from the command line as "tsocks thunderbird" or create a desktop file in .local/share/applications/mozilla-thunderbird.desktop and to the "Exec" line prepend "tsocks".

Pidgin - At least in my case Pidgin connects to a server outside the corporate firewall so

sudo yum install pidgin

was all that was needed and then basic config via the GUI where the address of the server is configured, the password and the protocol(s) desired are easily entered. Pidgin does support the use of the Gnome Proxy Settings but it didn't really apply in my case.

Gnome proxy settings break the Gnome Shell weather extension:

As I pointed out here, the Gnome Shell weather extension cannot execute its queries to the server when the Gnome Shell proxy settings are not set to "none". The weather extension is written in javascript as is the proxy autoconfiguration file. One might thing that this would be a "good thing" but apparently it's a bad thing as bad things happen when these two pieces of javascript collide. There is no known fix or workaround (other than manually going to your favorite weather site to check the weather) - but don't expect it to update your top panel in gnome shell until you turn off proxy settings.

Putting all this together with the Gnome Shell:

Up until now we have a complete solution except the SSH tunnel is invoked from the command line. To make things more Gnome Shell friendly grab the Gnome Shell Connection Manager Extension from here or from here, create an entry for, and you will now have a Gnome Shell panel utility that you can just click on and your SSH tunnel will be created for you. One trick in using this utility is that all the extra arguments go in the "host" field so in our working example the "host" is configured as "-L -D 1080". Note that the username is inserted by the utility before the server name. This assumes the username is the same on the local and remote systems. 

The more general solution is to configure a .ssh/config file and point the connection manager to this file. Once this is done all that is needed is to click on the connection manager, click on the particular connection desired, and then type in the password (if the password is of the one-time variety) in the spawned terminal window.

At the same time the Connection is toggled the Network Manager Proxy settings need to be toggled (by the user) and things work as set forth in the requirements section.

Confirming that it all works:

To confirm that the traffic that belongs in the SSH tunnel is indeed going there simply try accessing a resource that is inside the corporate firewall (web, email, ldap, etc.). This will simply not be possible if it has not been routed through the SSH tunnel. To confirm that non work-related traffic is being routed normally and not through the tunnel, I used tcpdump and was able to see the traffic "in the clear" which would not be possible were it inside the tunnel. 


Popular posts from this blog

Hit failing alternator with a hammer to confirm diagnosis of failing alternator due to bad brushes

alternatives --install gets stuck: failed to read link: No such file or directory

Thunderbird Stuck in Table Editing Mode