HTTP tunnelling

There plenty of articles, written on this topic. The main idea is to use the proxy's ability to forward all traffic on some particular port (see RFC 2817). By default proxies have a restricted set of ports where you can connect to (HTTPS[443], rarely HTTP[80] and another proxy[8080]). If you just want to setup a proxy, launch your service on external server on a given port and forward the traffic using any of plenty available utilities. This article mainly focuses on the case, when on the remote server you want also to have normal HTTPS and still benefit from tunnelling.

Very simple: proxying support is a standard feature of Apache package. You need to enable the mod_proxy.so and mod_proxy_connect.so module available. I use the following configuration in main configuration file:

LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so
LoadModule proxy_connect_module /usr/lib/apache2/modules/mod_proxy_connect.so

<IfModule mod_proxy.c>
    ProxyRequests On

    AllowCONNECT 22 993 5901

    <Proxy *>
        Order deny,allow
        Deny from all
        # Allow connections from localhost, localnet and my office:
        Allow from localhost 192.168.0.0/16 .myoffice.com

        # Uncomment below to enable authentication:
        #AuthType Basic
        #AuthName "Proxy Service"
        #AuthUserFile ...
        #Require valid-user
    </Proxy>

    ProxyVia Off
</IfModule>

For more information about used directives refer Apache documentation.

Now we have to find/choose some utility, that actually does the job. I recommend proxytunnel (the version 1.9.0 for Windows can be downloaded here). First of all, it supports 2 proxies in a chain, SSL encryption and NTLM authentication.

Ok, let's make a first try:

> proxytunnel.exe -v -p proxy:8080 -r myserver.com:443 -d localhost:22
Local proxy proxy resolves to 10.0.1.1
Connected to proxy:8080 (local proxy)

Tunneling to myserver.com:443 (remote proxy)
Communication with local proxy:
 -> CONNECT myserver.com:443 HTTP/1.0
 -> Proxy-Connection: Keep-Alive
 <- HTTP/1.0 200 Connection established

Tunneling to localhost:22 (destination)
Communication with remote proxy:
 -> CONNECT localhost:22 HTTP/1.0
 -> Proxy-Connection: Keep-Alive
analyze_HTTP: readline failed: Connection closed by remote host

Ops. Something goes wrong. We have forgotten to switch on SSL, because myserver.com expects SSL traffic on port 443. So we need to encrypt the data, which is send to first local proxy:

> proxytunnel.exe -v -X -p proxy:8080 -r myserver.com:443 -d localhost:22
Local proxy proxy resolves to 10.0.1.1
Connected to proxy:8080 (local proxy)

Tunneling to myserver.com:443 (remote proxy)
Communication with local proxy:
 -> CONNECT myserver.com:443 HTTP/1.0
 -> Proxy-Connection: Keep-Alive
 <- HTTP/1.0 200 Connection established

Tunneling to localhost:22 (destination)
Communication with remote proxy:
 -> CONNECT localhost:22 HTTP/1.0
 -> Proxy-Connection: Keep-Alive
analyze_HTTP: readline failed: Connection closed by remote host

Ops, the same trouble. Seems to be the same, but the ground is different. After short lookup in Google I came to bug#29744 (vote for it!) in Apache's bugtracker. The problem is that mod_proxy_connect.so is writing to the socket directly instead of going through the filter stack, and thus is not ready for CONNECT over HTTPS.

To overcome the problem, Apache server should be patched and rebuild. Download the patch for your Apache version (v2.2.9 in my case). Then run the following commands:

# sudo apt-get source apache2
# sudo apt-get build-dep apache2
# dpkg-source -x apache2_2.2.9-10+lenny2.dsc
# cd apache2
# patch -p1 < ../mod_proxy_connect-2.2.9.patch
# dpkg-buildpackage -rfakeroot -b

The contents of the directory after sudo apt-get source apache2 in my case looks like this:

# ls -l
-rw-r--r-- 1 root   root   135425 Jan 20 19:02 apache2_2.2.9-10+lenny2.diff.gz
-rw-r--r-- 1 root   root     1673 Jan 20 19:02 apache2_2.2.9-10+lenny2.dsc
-rw-r--r-- 1 root   root  6396996 Jun 14  2008 apache2_2.2.9.orig.tar.gz
-rw-r--r-- 1 root   root    12349 Jan 26 23:56 mod_proxy_connect-2.2.9.patch

Ok, now we need to install the hot build package:

# dpkg -i apache2_2.2.9-10+lenny2_all.deb

and try again the tunnel:

> proxytunnel.exe -v -X -p proxy:8080 -r myserver.com:443 -d localhost:22
Local proxy proxy resolves to 10.0.1.1
Connected to proxy:8080 (local proxy)

Tunneling to myserver.com:443 (remote proxy)
Communication with local proxy:
 -> CONNECT myserver.com:443 HTTP/1.0
 -> Proxy-Connection: Keep-Alive
 <- HTTP/1.0 200 Connection established

Tunneling to localhost:22 (destination)
Communication with remote proxy:
 -> CONNECT localhost:22 HTTP/1.0
 -> Proxy-Connection: Keep-Alive

Tunnel established.

Works!

When executing the tunnelling utility it is handy to hide the console. Well, try one of these utilities:

• hStart, which allows to execute several binaries at a time
• run utility, which seems to be a part of Cygwin

Tunnel:

proxytunnel.exe -X -a 22 -p proxy:8080 -r myserver.com:443 -d localhost:22

First of all, after forwarding the 22^nd port, you can use any SSH client, for example for the case of OpenSSH for Windows:

C:\OpenSSH\bin\ssh dmitry@localhost

Another alternative is Putty's plink¹⁾.

I agree, that running SSH-over-HTTPS tunnel is a bit excessive, but there is only one way to do it.

Similar you can tunnel local 993 port to e.g. Gmail:

proxytunnel.exe -X -a 993 -p proxy:8080 -r myserver.com:443 -d imap.googlemail.com:993

Now you either use localhost:993 in your Thunderbird settings, or add 127.0.0.1 imap.googlemail.com to your hosts file.

Tunnel:

proxytunnel.exe -X -a 5901 -p proxy:8080 -r myserver.com:443 -d localhost:5901

I will not go deep into explaining of VNC technology. VNC server emulates the X Window Server (for example in headless environment) and allows remove clients to connect to the server via binary RFB protocol and to communicate to programs, launched under this X Window Server. I recommend to use TightVNC – a FOSS alternative (for more details on this see VNC).

X Server will tunnel it's flow via SSH. That is a standard feature of sshd daemon and ssh client to enable X Forwarding. The idea is that SSH client opens a local port and forwards it to remote sshd, which opens any port on the server and listens for incoming connections. SSH client also tunes the remote environment so that X applications think they are connecting to local X Server, which is actually forwarded. In this case you should not bother about X Authentication.

I recommend to use Xming server, but there are other alternatives²⁾.

• Punching holes into firewalls
• Tunneling TCP Services over HTTP(S)
• Tunnelling SSH over HTTP(S) with Apache server
• pwnat - NAT to NAT client-server communication