OpenSSH 4.3

[Oliver Fromme]

Csaba Henk <csaba.henk at xxxxxxx> wrote:
 > [OpenSSH 4.3]
 > Hm, I'm reading in the announcement:
 > 
 > * Add support for tunneling arbitrary network packets over a
 >   connection between an OpenSSH client and server via tun(4) virtual
 >   network interfaces. This allows the use of OpenSSH (4.3+) to create
 >   a true VPN between the client and server providing real network
 >   connectivity at layer 2 or 3. This feature is experimental and is 
 >   currently supported on OpenBSD, Linux, NetBSD (IPv4 only) and 
 >   FreeBSD. Other operating systems with tun/tap interface capability 
 >   may be added in future portable OpenSSH releases. Please refer to 
 >   the README.tun file in the source distribution for further details
 >   and usage examples.
 > 
 > Getting this work on Dfly would be neat...

That feature is nice, especially because you can use the
standard SSH features for creation, authentication and
encryption of the tunnel (e.g. via .ssh/authorized_keys,
PAM challenge-response, whatever).

BUT ...  tunneling TCP over something which is itself
based on a TCP connection (in this case: ssh) doesn't work
well as soon as you try to transfer any significant amount
of data over that tunnel and there's the slightest trace
of packet loss or delays.  It will soon stall and timeout.
The reason for that is explained here:

http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

In general, OpenVPN works much better.  It uses UDP instead
of TCP by default.  Other than that, it works pretty much
the same as that tunneling feature in OpenSSH 4.3, i.e. by
creating a tun(4) or tap(4) device pair which is tunneled
through an SSL/TLS channel.  Only the authentication is
different (OpenVPN uses certificates instead of SSH-style
authentication).  See:  http://www.openvpn.net/

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd

Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.