There are a number of benefits to setting up a PPP-SSH VPN. It's relatively simple, it uses common off-the-shelf tools, and it probably won't require a reboot before bringing up the link. Here's a more comprehensive list:
You probably won't need to patch or recompile your kernel, run LILO, reboot, or perform any other perilous administration activities. PPP and SSH are included with most distributions, and most kernels come preconfigured to use them properly.
You should not have to edit any existing configuration files. You simply customize the script file provided later in this document, which contains all the VPN configuration info, and then execute it on the client machine. Any existing PPP or SSH configurations should continue to work just fine.
If the SSH protocol currently traverses your firewall, then PPP over SSH will traverse your firewall as well. (If you aren't using SSH, then why not? It is almost a required tool for system administrators nowadays.)
pppd automatically sets up routing for you. And, if you have very complex routing needs, it's very easy to put the custom routing commands in the script file.
PPP-SSH VPNs have no trouble whatsoever with dynamic IP addressess. The client must be able to find the server to connect to, of course, but dynamic DNS would work fine for that. Setting up a VPN over a dialup connection is no problem.
It's easy to set up multiple tunnels to a single computer. You simply need to make sure that the IP address for each tunnel's network interface is distinct.
This type of VPN is not without a few difficulties. Basically, it doesn't run unattended very well. If you're looking for a production-quality VPN that you can set up and forget about, you will proabably find PPP-SSH a little disappointing. Some alternatives are described in Section 2.4.
If the SSH TCP connection is broken for any reason, your VPN goes down hard and takes all tunnelled TCP connections with it. If you have a less than reliable link -- say it's difficult to download more than a few tens of megabytes at one go -- you will be re-starting the VPN a lot.
The TCP protocol consists of streams layered on top of IP packets. When you then run IP packets over the TCP stream (as we're attempting to do), the personality conflict between the two can become very apparent. Mostly, this manifests itself as weird delays, dropouts, and oscillations. Sometimes you'll see problems at load, sometimes with next to no traffic. Short of changing the entire OSI model (ha ha), there's not much that can be done about this.
For some reason, when network load gets high, one tunneled TCP connection tends to get all the bandwidth and the others get ignored. This leads to timeouts and dropped connections. Theoretically, this is fixable.
Keepalives are small packets sent to tell the machine on the other end that the connection is still up. If the network load gets too high, keepalives will be delayed. The other machine will mistakenly assume the connection has been dropped and take down its end of the link.
Without keepalives, however, there's no way for either machine tell if the link has been dropped. When one machine tries to bring the link back up, if the other machine thinks it already has it up, confusion can reign. Most often this will show up as multiple ppp network devices, duplicate routes, and tunnels that appear to be up but drop every packet. A liberal use of "killall -9 pppd" will usually set things back in order. A more intelligent start script could probably improve this.
When I use regular PPP over a 56K modem and Postfix opens 10+ connections to deliver my outgoing mail, everything works well. However, when I try to run this exact traffic over a VPN tunneled over a much faster DSL link, it stalls out. Ping times skyrocket for a spell (2 minutes and beyond), traffic moves at a trickle for a while, then it stops completely. The only way to get packets moving again is to restart the tunnel. I'm not sure if this is a bug or an inherent limitation. Reducing the number of connections that Postfix maintains for outgoing mail fixed this problem for me..
Ping times over my 57.6 modem connection are normally in the 130-170 ms range. However, ping times for a PPP-SSH VPN running over the same modem connection are in the 300-330 ms range. Turning on PPP compression can help a lot if you're transmitting compressible data. Email is compressible, Vorbis files are not.
The VPN FAQ at http://kubarb.phsx.ukans.edu/~tbird/vpn/FAQ.html is a very good resource. It's comprehensive, kept reasonably up-to-date, and not afraid to express an opinion.
If your kernel doesn't already have PPP and IP Forwarding capability built-in, the Linux Kernel HOWTO will tell you how to recompile your kernel to add it. It will also tell you how to load and unload the PPP kernel modules.
Tells how to install and set up the PPP daemon if your distribution did not automatically install it for you. Also has an excellent section on linking two networks using PPP. That's pretty much what we're doing, except that we're also encrypting it. You can find it at http://www.linuxdoc.org/HOWTO/PPP-HOWTO/index.html.
I wish there were an SSH HOWTO! For now, the documentation that comes with your distribution should be a good start. You might also check the OpenSSH web site.
If you're not very familiar with networking, you'll want to scour the Linux Network Administrators Guide. It's an excellent introduction to most of the concepts we'll be using here. You may also find the Linux Networking HOWTO at http://www.linuxdoc.org/HOWTO/Networking-Overview-HOWTO.html to be a useful introduction, especially itse sections on TCP/IP, PPP, and tunneling.
There are a ton of VPN technologies in the world now. If PPP-SSH doesn't fit all your needs, you might want to check one of the following packages.
ipsec describes a set of low-level protocols, ESP and AH, to perform authentication and encryption at the packet level. It also uses a higher-level protocol, IKE, to negotiate connection parameters and exchange encryption keys.
FreeS/WAN is probably the best Linux ipsec implementation today. Although it can be very difficult to set up, especially for those who are not terribly familiar with networking, it is amazingly stable once it is working. You can find out more at the FreeS/WAN home page.
Another good, free ipsec implementation is Cerberus. Unfortunately, the National Institute of Standards and Technology only distributes Cerberus to US or Candadian citizens currently located in either the US or Canada. Therefore, depending on who you are, obtaining Cerberus ranges from moderately difficult to effectively impossible.
PPTP (Point-to-Point Tunnelling Protocol) is a Microsoft-developed VPN protocol, described in RFC2637. It is a very common and well-understood technology and has many mature implementations on all commonly-used computer platforms. However PPTP is generally considered to have somewhat weak security.
Probably the best Linux PPTP implementation is PoPToP, found at http://poptop.lineo.com/.
CIPE is Olaf Titz's protocol to encapsulate IP traffic over UDP packets. It has both a Linux version and a Windows version. I haven't used it yet, but it is in strong development and looks very promising. For more information, the CIPE-MASQ Mini-HOWTO is a terse but informative read.