Slashdot Mirror
Building Linux Virtual Private Networks
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.
New Riders' MySQL book is mighty fine; if this is half as good it'll be worth reading
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.
I suppose this is the same for almost all computer books, easy if you know how...
Building VPNs is a pain in the ass, regardless of whether you're using windows NT/2k or linux. Microsoft's documentation is sketchy (and in some cases completely wrong), and there are very few sources for building a VPN in Linux.
This book may make it easier to build a VPN, but it's kind of obsolete, now that the Linksys VPN router has been released, making it a matter of plugging in and turning on. Of course, if you have plenty of free time, but very little money, you might go for the book instead.
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.
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.
Work for Change & GET PAID!
for simple encrypted forwarding
LocalForward 8080 theproxy:8080
LocalForward 25 thesmtp:25
LocalForward 143 theimap:143
Don't forget your '-g' =)
IPSEC is wonderful, but many businesses don't think things through and use it for telecommuting. Why is this bad? Well, the way this works is that someone connects to the VPN system and gets a full tunnel that allows the authorized client to behave on the internal network as if it was actually there, bypassing the firewall. The problem here is pretty obvious. The client machine is not protected by a firewall,a nd so if the client is compromised, an attacker has a clear path straight past the firewall. So the effectiveness of the firewall is greatly reduced.
Now if you don't have a firewall protectecting the network, this won't hurt, but if you do, then a solution like ssh is somewhat more secure, as you only set up the tunnels you absolutely need to very specific hosts. While there is still a risk, it is greatly reduced and strikes a good balance between usability and security.
What IPSEC *is* good for is seamlessly connecting sites together without really expensive dedicated lines securely. While it makes no guarantee as to bandwidht or availability, it does provide almost the same level of security. If a company can't afford lines to sites but still wants to expand, IPSEC is ideal. I use it to connect my home private network to a friends home private network. The key here is that not only do you have to trust the clients whose keys you permit to connect, but you must also trust that the administrator of that client machine or network is sufficiently competent to keep his network secure, as the security of the two networks is tied a lot more closely together...
XML is like violence. If it doesn't solve the problem, use more.
From testimonies of traveling whatevers the people always complain that PPTP is very sloooow. They preferred using RAS in place, albeit a very expensive phone bill.
Most were of course higher level execs so their complaining actually mattered.
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
Why does every book need to include the magic 'L' word in the title nowadays?
Because they have a better chance of getting posted to the Slashdot homepage?
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
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?
-------
Warning: Slashdot may contain traces of nuts.
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
Anyone know of any ISPs (preferably outside USA) that will route stuff coming from a VPN (or any other type of encrypted tunnel) to The Internet? (i.e. from The Internet's point of view, it would be like I was a local user of that ISP, even though I'm physically somewhere else.) Doesn't have to be free beer.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Anybody out there have any success compiling and using OpenBSD's isakmpd on Linux?
I really need to use aggressive mode but the patches for freeswan are ancient/unmaintained.
A pointer would be greatly appreciated.
Here's this script I use to setup a quick and dirty VPN between my workstation at work and my home PC. It has to originate from work to get through the firewall but once setup, of course, packets can flow both ways. I call the script ssh-vpn.
/usr/bin/ssh -1 -o 'Batchmode yes' -t -l root $REMOTE_HOST /usr/sbin/pppd local ${REMOTE_IP}:${LOCAL_IP} 2> $tmpfile
You have to setup ssh correctly with rsa keys before it will work. You also have to download pty-redir. See the VPN mini how-to for more details.
#!/bin/bash
REMOTE_HOST=$1
REMOTE_IP=$2
LOCAL_IP=$3
if [ -z "$1" ] || [ -z "$2" ] || [ -z "$3" ] ; then
echo "usage ssh-vpn "
exit 1
fi
# this file holds the slave pty that the local pppd needs
tmpfile=/tmp/tmp$$
# start remote pppd
/usr/local/bin/pty-redir
# give the remote pppd process a little time to send its first connect request
sleep 5
#start local pppd
/usr/sbin/pppd $(cat $tmpfile) passive
# remove file that held the slave pty file name
sleep 5
rm $tmpfile
No offense, but anyone still relying on pty-redir should really use a more recent version of pppd which has the '-p' option to create a pty on it's own.
The ppp over (ssh/ssl) stuff in the book is much more complete, allowing you to make more than one connection, doesn't rely on best-guess 'sleep X' timeouts, and walks you through setting up ssh securely s.t. it can only be used to create the VPN, and doesn't require logging in as root from either endpoint.
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.
Windows 2000/XP's support for IPSEC is limited to transport mode. Tunnelling is handled by Cisco's Layer 2 Tunnelling Protocol (L2TP). Unless FreeS/WAN and KAME now support L2TP, IPSEC VPNs using Windows-native clients are limited to routable IP addresses all the way around.
Now NAT is evil---ask my friends, I rant about it all the time---but in the real world, one must be able to tunnel VPN traffic at least in one direction (into the company). Without support for L2TP in FreeS/WAN or commercial IPSEC clients in Windows, one cannot currently do this.
Please, I beg you, prove me wrong. I've been struggling to get Windows IPSEC working with KAME for some time now. And my copy of Cisco's Unity VPN client doesn't work on XP.
I'm proud of my Northern Tibetian Heritage
As a side note, if you use '-g', make sure you have iptables/ipchains/hosts.{allow|deny} rulesets enabled to make sure that only authorized machines can use the gateway. Otherwise anyone in the world can use your encrypted tunnel.
Ummm, we cover cIPe in the book. Would be a pretty crappy job if we hadn't.
I have just been playing with IPSec for the last couple of days and wanted to buy a book on the subject. While I managed to sucessfully make a VPN connection between 2 machine, I still need to read a great deal about what's under the hood. :)
So I looked at amazon also thinking that I could not go wrong with a book from O'Reilly, but after looking at the few stars it got I had been looking at this book and the one from RSA. Well, that does it. I'm getting this one.
Of which I have none. Are there any good web/''net resources for setting up a VPN under Linux? How about VPNs from Linux to Windows and vice versa? HOWTOs? Tutorials? Utilities like Apachetoolbox, but for VPNs? Thanks.
This is an EXCELLENT POINT that CANNOT BE OVEREMPHASIZED.
I recently had to set up tunnels to allow a set of NAT'd workstations (laptops runnin a mix of Linux and W2K) access a system on the inside of a remote firewall where SSH was the only available securable protocol. We needed to use the "-g" switch, and the need for filtering access was immediately apparent.
We ended up using a set of scripts to build the tunnel, including the necessary iptables rules.
As an aside, I'd check if hosts.allow|deny rules are sufficient - I think the ssh tunnel would make all connections appear to be coming from the host running the tunnel. (Can't check for myself right now)
I tried a few different methods of establishing a vpn between my apartment and my parents house (also home office). i used cipe for a while but after getting vtun working, it was a lot better.
i especially like the compression! i could copy a zip file from my computer to the server at the other end and the transfer rate was consistent with the bandwidth cap of my cable modem. but transferring something like an access database was a lot faster (access dbs can usually be compressed quite a bit). basically no point to zipping before transfer as it happens automatically.
vtun has quite a few options and methods of transport and i'd highly recommend it!
-- Joel
Unless your distro can with FreeSWAN, you have to recompile your kernel with modifications.
Non-US distributions like SuSE and Debian can include Freeswan in their list of apps. US based ones like Red Hat can't. But some lovely fellows at Steambaloon (a Linux security consulting firm - no, I work for someone else) produce source and binary packages of the original and updated Red Hat kernels (with the AC patches, extensive testing, and old 2.4 VM) with Klips, the kernel level part of ipsec, compiled in.
Let's see: provided I know FreeSWAN, I can grab a machine and start setting it up immediately. If I want to get something commercial and very expensive, I have to fill out how many forms, get approval from how many people, wait for it to get ordered how long? Exactly where are you starting your clock when you say "configured from GUI in a few hours?"
Why not use Bookpool? http://www.bookpool.com/.x/hhowgiv3a6/sm/157870266 6
/.'ed too. :-)
They are always cheaper for the techy books. I wish they would give me a cut for all the times I have sent people there. Now they will get
--Neal
Go IETF!