1. 9

  2. 8

    This really is an apples to oranges comparison - and it didn’t have to be. Yes, you can tunnel ports with ssh (oranges).. but you can also do full on (layer 1, layer2) Virtual Private Networking (apples)!

    From the ssh(1) man page:

         ssh contains support for Virtual Private Network (VPN) tunnelling using
         the tun(4) network pseudo-device, allowing two networks to be joined
         securely.  The sshd_config(5) configuration option PermitTunnel controls
         whether the server supports this, and at what level (layer 2 or 3
         The following example would connect client network with
         remote network using a point-to-point connection from to, provided that the SSH server running on the gateway
         to the remote network, at, allows it.
         On the client:
               # ssh -f -w 0:1 true
               # ifconfig tun0 netmask
               # route add
         On the server:
               # ifconfig tun1 netmask
               # route add
         Client access may be more finely tuned via the /root/.ssh/authorized_keys
         file (see below) and the PermitRootLogin server option.  The following
         entry would permit connections on tun(4) device 1 from user “jane” and on
         tun device 2 from user “john”, if PermitRootLogin is set to
           tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
           tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john
         Since an SSH-based setup entails a fair amount of overhead, it may be
         more suited to temporary setups, such as for wireless VPNs.  More
         permanent VPNs are better provided by tools such as ipsecctl(8) and
    1. 1

      Isn’t simple tunneling over SSH prone to TCP-over-TCP issues? Something like sshuttle would avoid these, as should OpenVPN over UDP.