Building Linux Virtual Private Networks

Richard Miller contributed this review of New Riders' entry to the field of VPN books. No suspense, he gives the book a big thumbs up -- read on below for his reasoning, in particular a comparison to the previously available alternatives. Building Linux Virtual Private Networks author Brian Hatch, Oleg Kolesnikov pages 408 publisher New Riders rating 10 reviewer Richard Miller ISBN 1578702666 summary Finally, a VPN book you can use.

Rants

I've been on the lookout for a good VPN book since I first bought the O'Reilly VPN book in 1998. Yes, that book shattered my long standing belief that O'Reilly could do no wrong. The technical descriptions of VPN technologies were flawed and confusing, and they seemed to think that the only usable VPN technologies were commercial products. They only showed you implementations via screen shots of point-and-click GUI sessions. The one potentially portable section describing PPP over SSH was practically copyright infringement from the HOWTO, but with enough errors that they could make the case they had never actually read it.

For a while the O'Reilly VPN book was the only one out there. Then a few other publishers got into the mix. Unfortunately their results were no better. I could never find a book that had both a description of the protocols that would allow you to debug problems and implementation details that weren't so vague that they could apply to the installation of my washing machine. I must have bought half a dozen VPN books, all of which were severly lacking in crucial aspects that would make them usable. I had little stickies placed in them showing me which parts were correct and helpful, and would flop between them all whenever I needed to do something, because nothing got it all right.

Now I'm not here just to flame these other books, but I must let you get an idea for how I was feeling, because only then can you understand how much happier I am now. Now I can finally throw away all those other books.

Building Linux VPNs was written by Brian Hatch (of Hacking Linux Exposed fame) and Oleg Kolesnikov, and published by the New Riders, the same guys who do the SANS publications. It's not as thick as you might expect, coming in at 408 pages, but it's remarkably dense in a good way. No wasted space for boring screen shots, instead concentrating on well tailored diagrams when needed, code listings, and command line sessions.

Overview

Part one, the first two chapters, teaches you everything you need to know about general VPN technology, and discusses all the VPN issues you're going to face: various different network topologies you could use, how to get your routing set up on both servers and clients, DNS setups, how to use VPNs with firewalls (and where they could go) and more. These are the issues that the trickiest to get right when actually setting up a VPN, and something most other VPN books leave up to the reader to figure out.

Part two discusses standard VPN protocols. The first two chapters of this section discuss creating a VPN with PPP over SSH and SSL. For those of us who have implemented PPP over SSH following the HOWTO before, you'll remember how hackish it felt. The authors have come up with a much more modular (you can have any number of VPNs easily) and secure (they teach you how to set up your SSH keys or SSL certificates securely) method, and provide you all the code to do it. Following the step-by-step instructions, you could make a PPP over (SSH/SSL) VPN in about 30 minutes. Rock on.

They then dedicate two chapters to IPSec: one for the description of the protocol itself (which definitely deserves a chapter) and then one for the implementation of FreeS/WAN. IPSec is known to be a difficult beast to ride, and they do a really great job of giving you the information needed to get it right.

The last chapter of this part covers PPTP for both server and client. I was shocked to see PPTP discussed in a Linux book, but I guess the authors say it best when they said:

"There are times when you must support PPTP, either because you are forced to connect to a server that only runs PPTP or because you need to support remote Windows machines. In either of these cases, we offer our deepest sympathies."

Part three discusses non-standard VPN protocols. In the same detailed fashion, the authors devote three chapters to alternative VPN technologies VTun, CIPE, and tinc. While these technologies do not have IETF protocol drafts, they are nonetheless well defined, and work on multiple Unix platforms.

Analysis

In this day and age of '2nd/3rd/4th Edition' it's good to see a book that really hit the nail on the head the first time. Building Linux Virtual Private Networks has all the technical information you need to understand the protocols, set up your networks, and troubleshoot, and has the implementation details to get it all done almost entirely pain free.

It's extreemly easy to read, has a consistent style and tone, and uses just the right amount of humor to keep you interested in something that could be an extreemly boring technical topic.

One nice thing is that they defined their network early in the book, and they implemented each separate VPN technology using the same network, including host names, IP addresses, etc. This consistency really pays off in clarity to the reader.

Beefs

There's a good bit of code in the book, which is a great thing. They mention throughout that you can download the code online at their website, but it doesn't seem to be there yet. Hopefully this will get rectified. (You can still get a preview, though, at the book's official website. Good to see folks who don't blindly use ".com" for everything. )

Also, a lot of the software they discuss works on *BSD, Solaris, some even on Windows. Why does every book need to include the magic 'L' word in the title nowadays?

Kudos.

You can purchase Building Linux VPNs from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Comments

Re:What's wrong with PPTP?

[Anonymous Coward]

It's Point-to-Point Tunneling Protocol and thus more limited than IPSec which can be used in routed mode and can connect arbitrary networks.

Re:What's wrong with PPTP?

[Junta]

Just FYI, but Win2k and newer (at least) include native IPSEC support that can interoperate with FreeS/WAN and such. Other systems, well, they are intended for home use that doesn't need that functionality..

Re:What's wrong with PPTP?

[jeremiahstanley]

With Win2k you can get this little patch and then you have a free as in beer IPSec implementation provided by Microsoft under Win2k. It even supports x509 certs. IPSec clients are not that expensive. Look at SSH Sentinal for another option. It even supports the newer AES ciphers (which I don't expect out of Microsoft for a long time)as added security.

For all of this you have to patch the code to use the newer ciphers. You can get that here and if you need to use x509 certs you can get that stuff here. This is all pretty easy if you have you druthers about compiling new kernels and working with OpenSSL.

Why this isn't in the kernel to begin with is anybody's guess. I would guess that it has something to do with all those pesky crypto export laws. Just like everything else in the ol US of A we have to sacrifice our freedoms so that we can be safe from the KGB and that one guy from Hackers.

Re:The main problem with IPSEC...

[Anonymous Coward]

Actually, this is bypassed by disabling split tunneling (allowing the client machine to access the internet "directly" and accessing the VPN tunnel).

-m

Re:The main problem with IPSEC...

[icedivr]

Your beef can be easily solved by ensuring that the remote machine's default route is down the tunnel.

As far as I'm concerned, a bigger threat is the road warrior laptop not having adequate virus protection. (VP of Sales does insist on Windows, doesn't he?) Desktops behind the firewall presumably have multiple layers of protection in front of them, the road warrior, maybe not.

CIPE - a better solution.

[ion]

I'm using CIPE for linux at work. It can be found at http://sites.inka.de/sites/bigred/devel/cipe.html or for windows at http://cipe-win32.sourceforge.net/.
It's a better solution because it doesnt run TCP over TCP, which can give a problem, when retransmission occurs. With the right ammount of bad luck, you can have double retransmission where both layers of TCP retransmit. CIPE runs completely over UDP to avoid this problem.

JonB

Re:CIPE - a better solution.

[Junta]

Better solution than, say, ppp over ssh (a really dumb hack), but not better than IPSEC for most all applications.

IPSEC also does not run TCP over TCP, it uses udp for isakmp, and data is transmitted through custom protocols (numbers 50 and/or 51), *not* through TCP.

Another thing about IPSEC that works better than CIPE is that IPSEC more strongly authenticates the machine at the other end. This is why NAT breaks, because unlike CIPE, IPSEC works to ensure the packet has passed unmodified since leaving a known trusted host, and the very nature of NAT prevents this. Solution is simple, move the IPSEC gateway to either the NAT system or beyond. Though it is being pushed in many circles as a good solution for telecommuting, it really was never designed for that and that usage really spits in the face of firewalls.

Finally, CIPE lacks compatibility. Sure you can configure windows and linux boxes and maybe other platforms, but just try to connect to, say a CISCO router....

CIPE is a hack that creates more problems than it solves in the long run. PPP over ssh is worse, but a dumb idea, set up tunnels for specific tcp services that you need, more overhead, but security is better (not perfect, but better). For connecting networks together, a good architect can piece together an IPSEC solution that guarantees identity at other end of the pipe... CIPE offers the gaping whole that IPSEC can while not offering enough identification. So ssh or IPSEC remains the best solution, depending on the problem.

PGPnet

[Jacco de Leeuw]

That's because NAI doesn't know what to do with it. Could they be dumping the product for $39? They want to sell off some parts currently included with PGPnet. There's some uncertainty if you buy the product. Will they update it? Will they fix bugs?

Re:Crossplatform aspect?

[Junta]

IPSEC "clients" for Windows:
PGPnet- commercial and free versions. Free version doesn't do complicated routing stuff
Windows 2000 and newer have built in IPSEC capabilities.

Both these methods can interact with CISCO, OpenBSD, and FreeS/WAN.

IPSEC is the best shot you have at a cross-platform standard.

Duh, we cover cIPe in the book.

[Brian Hatch]

Ummm, we cover cIPe in the book. Would be a pretty crappy job if we hadn't.

Re:ssh + ppp = vpn

[Junta]

Of course, ppp over ssh is a bad thing, ugly and bad. For most traffic, you have this topography:
TCP over IP over ppp over ssh over TCP over IP, etc...

Note the fact that we have TCP over TCP, which is bad, very very bad. If a packet gets lost, we have two layers doing the same thing to restore a connection and things can get stalled out quickly....

ssh's built in tcp tunneling suffices for most remote access applications. For a true VPN, IPSEC is the only good way to go. Other things like CIPE certainly work better than ppp aver ssh, but still lack in certain features things that IPSEC does. Then again, if you have to build a VPN where you need to modify packets in transit (i.e. NAT), CIPE is a viable alternative if you don't mind that packets could be mangled by more than just the NAT gateways and CIPE wouldn't care, but I personally want to ensure the highest security with IPSEC...