OpenBSD Journal
Home : : Add Story : : Archives : : About : : Create Account : : Login :
Tunnelling out of corporate networks (Part 1)
Contributed by sean on Tue Mar 23 20:05:20 2010 (GMT)
from the slacker-of-the-year dept.

Mark Uemura (mtu@) writes in:

Tunneling out of corporate networks (Part 1)

I have always been intrigued with encrypted network tunnels, be it ipsec(4) or ssh(1). Yet, I don't think that anything beats SSH VPN tunneling on OpenBSD for a quick, elegant and stealth-like solution without the IPsec headaches.

Read on to find out more about SSH VPN tunnels:

Articles 1 2 3 4 5

After discussing tunnels with Ryan McBride (mcbride@) and its implications for security and/or policy violations, he made a comment that he has yet to see a network that he was not able to tunnel out of. There are various tools in ports to do just that, assuming that you are not using IPsec or SSH. However, before I get into corporate policy violations and back-channel malware tunnels, I should back up in time to give some perspective and my experiences with VPNs.

At C2K6, I was working with Hans-Joerg Hoexer (hshoexer@) on IPsec failover VPNs using sasyncd(8). I also had the pleasure of sitting pretty close to Reyk Floeter (reyk@). He was the first person to introduce me to VPN tunnels using SSH. Reyk had a SIP phone that he was carrying around to call home with a SSH VPN using the tun interface. He developed this SSH VPN functionality with bits of code from Markus Friedl (markus@) and merged it into OpenSSH at the end of 2005. Since then, we have had the ability to create SSH based layer 2 or layer 3 VPN tunnels all handled at layer 7 :-).

It wasn't until last year that I started experimenting with this in earnest. Normally, I use SSH port forwarding with authpf(8) and key/passphrase authentication for most things and IPsec with authpf where port forwarding is not practical. Generally, with OpenSSH VPNs, you don't have to worry about Maximum Transition Unit (MTU) issues or firewalls getting in the way of the VPN. For the record, I'm not a fan of PKI so I have never gone down the ssl(8) VPN path.

SSH VPNs do their magic at the application layer (layer 7) without the headaches and baggage that come with traditional IPsec VPNs. Now, I can use OpenSSH to do what IPsec used to do for me in the past. IPsec on OpenBSD is really simple to set up but became more problematic with other Operating Systems. Yes, you need to work through this and familiarize yourself with IPsec implementations for each OS but it seems more complicated than it needs to be. OpenBSD has really simplified the setup and configuration of IPsec VPNs.

Unfortunately, in the real world, you often come across firewalls that block ESP/AH or ISAKMP/ISAKMP-NAT-T. Moreover, packet fragmentation caused by MTU issues were always a concern. If you didn't get the MTU just right, the user would run into fragmentation issues making the VPN really slow resulting in a negative end user experience. Lowering the MTU is really important in order to avoid this issue but in doing so, you inevitably reduce the maximum throughput of non-IPsec traffic. However, too many networks block icmp(4) or TCP MTU discovery which at times can cause "speed issues" with the road warriors you need to support. Well, with pf and scrub you can compensate for this but when you are dealing with Windows, changing the MTU is an all or nothing dilemma.

To the point, with SSH VPNs, you've got one of the most trusted of SSH implementations, OpenSSH, and all the security goodness that comes with it. Here's a simple config set borrowed from ssh(1):

How to use OpenSSH-based virtual private networks

(1) Server: Enable support for SSH tunneling (/etc/ssh/sshd_config):

	PermitTunnel yes

send the hangup signal (SIGHUP) to reload the new sshd_config

(2) Server: Restrict client and assign the tunnel (/root/.ssh/authorized_keys)

	tunnel="1",command="sh /etc/netstart tun1" ssh-dss ... my_id_dsa

(3) Server: /etc/hostname.tun1

	!/sbin/route add -inet

(4) Client: Configure the local network tunnel interface (/etc/hostname.tun1)

set up the layer 3 tunnel on the client:

	!/sbin/route add -inet aaa.bbb.ccc.0/24

(5) Client: Configure the OpenSSH client (in /root/.ssh/config):

        	Tunnel yes
        	TunnelDevice 1:any
        	PermitLocalCommand yes
        	LocalCommand sh /etc/netstart tun1

The following network plan illustrates the previous layer 2 configuration.                                  aaa.bbb.ccc.0/24
----------------                                  ----------------
    |                                                     |
    |                                                     |                                    AAA.BBB.CCC.DDD
+--------+               (          )                +--------+
| Client |--------------(  Internet  )---------------| Server |
+--------+               (          )                +--------+
    :                    :
           Forwarded ssh connection (Layer 3 tunnel)

--- real connection
... "virtual connection"

AAA.BBB.CCC.DDD   "Server public IP address"
aaa.bbb.ccc.0/24  "Private network behind above public IP address"   "Client private IP address"  "Private network behind above private IP address"

(6) Client: Connect to the server and establish the tunnel


when successful, you should see the following interface created on
the server:

tun1: flags=51 mtu 1500
        groups: tun
        inet --> netmask 0xfffffffc

(7) Client and Server: pf needs to be configured to allow and perhaps
hide networks on either side via NAT.  Essentially both the client and
the server have become VPN peers. The Client above is not directly 
connected to the Internet.  It is on a private network behind some
Internet router. Imagine the client inside some corporate network.

I went a little crazy to see how far I could take this. When forced to use Windows, I would configure VMWare and install OpenBSD as a guest and then create the SSH VPN. I could then pass traffic to and from Windows through the tunnel using OpenBSD and OpenSSH as the conduit. I've done similar things with Mac OS X but David Gwynne (dlg@) informed me that there are more elegant hacks that can be done when using a Mac. Obviously, running OpenBSD in VMWare just to create a VPN to tunnel out of some restricted network seems a little much and dangerous for many reasons but it is not too difficult to do. Alternatively, you can create the SSH VPN tunnel on a different machine running OpenBSD and turn it into a router for other machines to enjoy the tunnel too.

Now the benefits are that you don't have to worry about firewalls as most networks don't proxy SSL connections. Configuring your SSH server to listen on port 443 and/or port 53 eliminates firewall issues most of the time. Since we are using OpenSSH for this VPN, we also don't have to worry about fragmentation issues :-). Thanks Reyk!

The above discussion is background info for another article that I have in the pipeline. In the meantime, I would be very curious and happy to hear what others have to say about their experience with SSH VPN tunnels using the tun interface. I am also interested in what packages and efforts you go through to break out of supposedly secure proxied networks.

Mark T. Uemura

What a tease! Thanks Mark for explaining this underused feature of ssh and we're anxiously waiting for the second part!


<< Inside the DEFCON 17 Network | Reply | Flattened | Expanded | Switching CVS repositories. >>

Threshold: Help

Related Links
more by sean

  Re: Tunnelling out of corporate networks (Part 1) (mod -3/41)
by Dan Shechter G (danshtr) ( on Thu Sep 3 18:47:36 2009 (GMT)
  Very interesting read. Thanks!

Are these papers are relevant to OpenSSH TCP tunneling implementation?

Maybe the internet today is better then when these papers where written.
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

  Re: Tunnelling out of corporate networks (Part 1) (mod 4/40)
by jirib (jirib) ( on Thu Sep 3 18:48:42 2009 (GMT)
  not exactly related to OpenBSD but I have to use commercial socks 5 server with SSL extension (see, but there is not opensource socks client which supports it :(

does ATTclient run under OpenBSD? any experience? it does exist for linux.
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

  Re: Tunnelling out of corporate networks (Part 1) (mod 0/38)
by Ed Ahlsen-Girard (girard) ( on Thu Sep 3 19:42:11 2009 (GMT)
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

  Re: Tunnelling out of corporate networks (Part 1) (mod -1/43)
by Wild K.H. (lynxxx) ( on Fri Sep 4 07:38:05 2009 (GMT)
  >> I've done similar things with Mac OS X but David Gwynne (dlg@) informed me that there are more elegant hacks that can be done when using a Mac.

I would be very interested in more detail informations about this topic.
Are there any?

  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

  Re: Tunnelling out of corporate networks (Part 1) (mod -3/37)
by Guy (guy) ( on Fri Sep 4 14:02:37 2009 (GMT)
  As you point out, you can put your SSH service on port 443 or 53.

To make it more certain that you can access your SSH server from a corporate network, you can multiplex port 80 for both SSH and HTTP on your outside server.

The concept is simple (tool: 'portknock')
- run a webserver on port 80
- have a process watch for access to a certain page on the webserver
- when the page is accessed, have the process add the source address to a pf table
- preconfigure a rule in pf for all access from the source address to port 80 of the server to be redirected to port 22
- now, access to port 80 from the source address will provide an SSH service (but web service for everyone else)
- quickly expiring the port forward rule will make the service revert back to a webserver, even for the designated source address, but the state will remain for the existing SSH session

  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

  Re: Tunnelling out of corporate networks (Part 1) (mod 6/38)
by Anonymous Coward (DoctorPhish) on Fri Sep 4 16:52:37 2009 (GMT)
  My employer and I have been having an (unintentional) arms race in regards to tunneling out.
The setup consists of a windows box with cygwin connecting to an OpenBSD firewall.
At first, it was relatively simple. I just needed to get past the NTLM authenticated proxy, which was easy with NTLMAPS.
The proxy also didn't allow encrypted traffic over any port but 443, so using pf to redirect the port 443 from said employer's public IP made the setup work.
Then, they upgraded the proxy, and it started rejected non-ssl traffic over port 443.
This took a bit more thinking, but using nc to SSL encrypt the SSH traffic, and using stunnel to listen on the other end made the whole thing work.
Of course, my boss knows that I'm doing this, and have actually used it to save the day; allowing the accountants access to legitimate business websites that the corporate proxy unintentionally mangled (ie. anything not using standard ports). It took them a year to get it working with the corporate proxy.
I wouldn't suggest poking through corporate firewalls without permission, as the consequences of being caught would likely be severe
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

  Re: Tunnelling out of corporate networks (Part 1) (mod 3/35)
by Jeff Quast (dingo) ( on Fri Sep 4 17:00:49 2009 (GMT)
  I have yet to see a vpn I couldn't tunnel out of either, but they are beginning to make it hard. The most obnoxious one I ran into a few years ago was a web proxy appliance that required NTLM (windows) authentication. Lucky for me, there was a python-based program that was able to tunnel a single tcp connection through it, and after a few edits, i was able to coerce it to work and get out with ssh.
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

  Re: Tunnelling out of corporate networks (Part 1) (mod 3/33)
by Brynet (Brynet) on Sat Sep 5 00:44:37 2009 (GMT)
  IP over ICMP =
TCP over ICMP =
IP over DNS =
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

  Re: Tunnelling out of corporate networks (Part 1) (mod -2/34)
by Jul_bsd (jul_bsd) ( on Sat Sep 5 12:13:14 2009 (GMT)
  Super stuff !!!

any way to allow this for non-root user ?
Most of the time i block root user in sshd. and i hope most admin do the same.

So, something like this would be great (server side)

Match user xxx
PermitTunnel yes
ForceCommand "sh /etc/netstart tun1"

or maybe we can manually connect to the server and call netstart with sudo ?

but the problem is the same on client side.
maybe a "LocalCommand sudo sh /etc/netstart tun1" could work
and after there is portability problem with Windows/putty ...

Anyway, thanks a lot for this tuto
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

  Re: Tunnelling out of corporate networks (Part 1) (mod -1/21)
by Gilbert Grape ( ( on Mon Sep 29 11:17:14 2014 (GMT)
  The tunneling out of corporate networks can be tricky. It is better to use SSH VPN, as the task is not simple. Controlling the MTU is the most significant part in this process. Thanks a lot for sharing this informative article. what is cloud storage
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

  Re: Tunnelling out of corporate networks (Part 1) (mod -1/11)
by mxffiles ( on Tue Feb 7 06:59:46 2017 (GMT)
  This is a very good post which I really enjoy reading. It is not every day that I have the possibility to see something like this. Software mxf Software mxf converter free download to convert HD camcorder files. ts converter convert ts video files to avi, mp4, wmv, mov mts to avi mp4 mov mkv iMovie, FCP/FCE with mts converter, so to convert mts files for your PC and mobiles. mod converter and convert tod files just free download mod video converter. m2ts
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

[ Home | Add Story | Archives | Polls | About ]

Copyright © 2004-2008 Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to April 2nd 2004 as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. Some icons from used with permission from Kathleen. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. Search engine is ht://Dig. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]