Slashdot Mirror


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.

9 of 104 comments (clear)

  1. What's complicated about FreeSWAN? by Anonymous Coward · · Score: 4, Interesting

    They have excellent documentation and they keep the documentation trees for older versions online. Installation is as complicated as running a skript and installing the recompiled kernel, if even that. I guess it never hurts to have more documentation, but saying that IPSec is "a difficult beast to ride" produces more awe than necessary.

    1. Re:What's complicated about FreeSWAN? by LWolenczak · · Score: 3, Interesting

      The FreeS/WAN people don't document everything that you can do with frees/wan. Its very neat when you get down to the point where your playing with dozens of tunnels confiugred every which way.

      One of the things that they don't tell you how to do, i guess so they don't get asked questions, is how to put gre traffic inside of an ipsec tunnel and make it work right. Also, it seems to have slipped by that you CAN make two linux 2.4 secure gateways talk to each other over the ipsec tunnel.

      I have a couple samples of some of the neat things I have done at http://lwolenczak.net/ipsec.html

    2. Re:What's complicated about FreeSWAN? by Etyenne · · Score: 3, Interesting

      Complicated thing with FreeSWAN :

      - Client behind NAT

      - Left/Right side nomenclature really confuse me; they could have used "peers" or client/server, I don't know

      - Recompiling kernel; easy if you have a single box, quite hard when you manage 30+. Plus it require you to commit the sin of rebooting the machine.

      At work, we have choosen CIPE for Linux-Linux VPN. It is totally userland, come stock on recent RedHat version and is available as RPM; all that make it is easy to install and upgrade on a lot of machines. Plus the config file is really dumb-proof. We are stuck using PPTP for Windows-Linux VPN because that's all the Windows monkeys know about.

      --
      :wq
  2. What's wrong with PPTP? by Jacco+de+Leeuw · · Score: 4, Interesting
    PPTP is often used for 'road warrior' setups, i.e. people working from home or on the road. It's cheap because there are free (as in speech) PPTP servers for Linux and the Windows PPTP clients are free too (as in beer). In contrast, Windows IPSEC clients are often expensive.

    So, what's wrong with it then? Well, the security of PPTP apparently depends on the password. A German student has written software which can crack the password in a couple of hours on a Pentium II.

    c't (Heise) reported about this.

    --
    -------
    Warning: Slashdot may contain traces of nuts.
    1. Re:What's wrong with PPTP? by FallLine · · Score: 3, Interesting

      Well firstly, Microsoft's implimentation of PPTP is insecure, buggy on the client side (and the server side, where their server is used), and has a hard time supporting multiple clients in a NAT environment.

      Secondly, a lot of older hardware has little to no support for the GRE protocol that PPTP depends on. Thus many people simply can't use it.

      Thirdly, it's virtually impossible to get two people connecting to the same VPN behind the same NAT network on any hardware. The nature of GRE makes it very difficult since it has no concept of port to diffentiate between packets, only source and destination IP. Unfortunately, NAT is very common these days so this really does matter.

  3. Problem is getting Management to go along by Cy+Guy · · Score: 2, Interesting

    I think the priority should be getting management to understand the importance of using standard protocols instead of proprietary ones.

    Having a book like this one is great if you want to familiarize yourself with the standards and how to implement them on Linux, but the much harder task is getting Management, particularly at larger companies, to see the benefit of implementing a standards based VPN where the users can use any standards based client over any TCP/IP network.

    Instead what I see is managers that want to buy a single product that comes with both the server and client applications, but then doesn't work or is hard to implement when the clients are trying to access the VPN from a cablemodem, DSL, or 802.11 connected machine, and don't (God forbid) want to use MSIE and Citrix on Windows to get onto the office network.

  4. Re:VPN hardware by Cyno · · Score: 2, Interesting

    ...or if you're worried about security. I never trust commercial companies to deliver secure code. Specially if they keep it closed source. Unless you want to flash the rom on this thing every few weeks I'd just read up on a linux ppp over ssh solution and write some scripts to keep that software updated.

  5. Crossplatform aspect? by egghat · · Score: 2, Interesting

    How is the crossplatform aspect covered? There are hundreds of possible solutions for VPNs out there, but if you want something that works on *nix, Windows and Mac (Classic and X) and is free and open, the range of products to choose from gets small ...

    For example, I couldn't find a free IPSEC client for Windows.

    Any new hints from this book?

    Thanks in advance.

    egghat.

    --
    -- "As a human being I claim the right to be widely inconsistent", John Peel
  6. IANACLB by hey! · · Score: 4, Interesting

    IANACLB (I Am Not a Command Line Bigot), but doing better than a CLI interface in an area like this is a tall order. It's not something you can just slap onto the product in a few days (as most VPN box configuration GUIs I've seen appear to be).

    The problem with the GUI interfaces I have seen is that they really don't give you any effective conceptual support. You have to figure out the topology and requirements of your network, then you do this bit of intellectual gymnastics that turns these global requirements and properties into settings for each individual box, THEN you sit down at your GUI. At that stage, the GUI can have very little benefit, since you are talking about a half dozen relatively simple commands you need to type in. In fact, typing them in means you can keep them in a little word processor file and send them to the box over and over again with little changes -- good for setting up multiple boxes or for playing around with a single box you are repeatedly pin-resetting.

    To really help a person like you who doesn't have time to bone up on every box you are working with, what you really need is something that is kind of a cross between a network management system and a CAD system. You would sketch out your network, and drop little dollops of distinctively colored "paint" on each network or host that needs to participate in some virtual network. The system would then output configurations to download to each of the participating firewalls or hosts.

    A GUI that just configures and individual box does practically nothing for you.

    --
    Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.