December 24, 2005

A VPN for the common man!

In the rumbling debate about VPNs and how they should be done, here's a new entrant as found in an interview with Damien Miller (spotted on Matasano):

The upcoming OpenSSH version 4.3 will add support for tunneling. What type of uses is this feature suited for?

Damien Miller: Reyk and Markus' new tunneling support allows you to make a real VPN using OpenSSH without the need for any additional software. This goes well beyond the TCP port forwarding that we have supported for years - each end of a ssh connection that uses the new tunnel support gets a tun(4) interface which can pass packets between them. This is similar to the type of VPN supported by OpenVPN or other SSL-VPN systems, only it runs over SSH. It is therefore really easy to set up and automatically inherit the ability to use all of the authentication schemes supported by SSH (password, public key, Kerberos, etc.)

The tunnel interfaces that form the endpoints of the tunnel can be configured as either a layer-3 or a layer-2 link. In layer-3 mode you can configure the tun(4) interfaces with IP or IPv6 addresses and route packets over them like any other interface - you could even run a dynamic routing protocol like OSPF over them if you were so inclined. In layer-2 mode, you can make them part of a bridge(4) group to bridge raw ethernet frames between the two ends.

A practical use of this might be securely linking back to your home network while connected to an untrusted wireless net, being able to send and receive ICMP pings and to use UDP based services like DNS.

Like any VPN system that uses a reliable transport like TCP, an OpenSSH's tunnel can alter packet delivery dynamics (e.g. a dropped transport packet will stall all tunnelled traffic), so it probably isn't so good for things like VOIP over a lossy network (use IPsec for that), but it is still very useful for most other things.

The problem with VPNs has been partly key management nightmares (a.k.a x.509) and partly install and configuration nightmares. For those reasons, VPNs only really made it into areas where corporates could pay people to get them up and going.

Adding it to SSH solves both those issues and promises to bring about VPNs for the common Unix machine (including all Macs now).

Crazy Prediction Time :- within a year of this being released and available, SSH will be the most popular VPN. Within two years, we'll even forget that VPN stood for anything other than a way in which we use SSH.

Posted by iang at December 24, 2005 08:24 AM | TrackBack
Comments

A spirited article on VPNs recommends OpenVPN, being a userland deamon that obviates all the IPSec kernel stuff and lets you install and configure easily. Especially useful to get a view on the two alternates, IPSec and SSL VPNs, but make sure you read the comments to get the old guard's replies.

http://software.newsforge.com/article.pl?sid=05/09/22/164231&tid=78&pagenum=2

I don't like VPNs much myself, and OpenVPN looks like it has the same problem: how do you know it is turned on? For my money, security begins and ends at the Application, that which we call the Finance layer, and VPNs are just too remote for that to work out.

Posted by: recommending OpenVPN - the competition! at December 25, 2005 07:31 PM

You didn't see my wiki entry about openvpn?

uses OpenWrt and OpenVPN to make a super cheap embeded wifi/vpn router :)

http://wiki.cacert.org/wiki/OpenWRT

Posted by: Duane at December 27, 2005 11:39 AM

Will the new ssh-vpn not use TCP to transport the underlying packets? I've been using ppp-over-ssh as a VPN for almost a decade: it's super-easy to set up, and the only privilege you need is being able to run pppd. But since everything gets tunnelled over TCP, lots of Badness starts happening when packets start getting lost.

Posted by: Ian at December 27, 2005 11:41 AM

OpenVPN is my preferred option since it uses UDP for transport rather then TCP

Posted by: Duane at December 27, 2005 12:33 PM
Post a comment









Remember personal info?






Hit preview to see your comment as it would be displayed.