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.
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.
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.
Sometimes, there are special constraints on the networks you are working with. For instance, I need to use stuff that uses IP, but since PPP over SSH is strictly TCP, I can't use that option. Moreover, my boss is a paranoid guy that doesn't trust some 24-year-old punk (me) to run his firewalls, so both offices have managed firewalls through different ISPs, ruling out the possibility of a single ISP routing traffic over its network to the other office so that I don't have to do anything. This adds additional constraints because since I can't control the firewall without going through pains with both ISPs for several days, I can't even open a port for something like PPTP (which I really wouldn't want to do anyway). Granted, I can probably find out what I need to know from a Google search, but it would be nice to have all the common VPN solutions covered--even just introduced--in a book format. I'm buying it.
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' =)
Not to mention their GTK/Gnome Development book.
I have as much respect for New Riders as I do for O'Reilly.
LedgerSMB: Open source Accounting/ERP
...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.
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.
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
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.
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.
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.
It's not when it works you need the books. It's when it doesn't work you'd wish you had the book.
I have configured a VPN with the help of a HOW-TO page and it worked. B
ut when you want to do larger setup's in the "real" world. All kinds of questions comes and demands comes to mind and it's nice to be on top of things and be able to say from the first meeting, what is possible and what is not.
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...
XML is like violence. If it doesn't solve the problem, use more.
L2TPd for linux exists, separate from FreeS/WAN. Though commonly coupled with IPSEC, L2TP is separate. I have heard reports that FreeS/WAN+l2tpd can be used to provide the functionality you describe to have a pretty solid VPN with FreeS/WAN and Windows ends.
http://www.marko.net/l2tp/
A bit dated, but reportedly still functional...
Now as far as getting connectivity to Cisco with Windows with tunneling, I have no idea, never tried...
XML is like violence. If it doesn't solve the problem, use more.
Of course, ppp over ssh implies a full IP tunnel using ppp with ssh underneath, IP in TCP encapsulation, essentially. You get full IP functionality this way, though the architecture is horribly flawed (TCP connections run with TCP somewhere underneath, very bad when packets get loss and two layers start doing recovery).
Now ssh without ppp on top supports only TCP tunnels, I'll assume that is what you are talking about. A statement that says you need to use IP, but you only get TCP sounds really goofy, since TCP rides on top of IP, phrasing it with the protocols you need (i.e. udp, icmp, etc) would have made the post more sensible (that and omitting ppp...). If I heard someone make the statement you just made I wouldn't trust them with firewall configuration either...
XML is like violence. If it doesn't solve the problem, use more.
Are you saying that ICMP, or UDP, traffic is unable to utilize this tunnel?
That is certainly not correct. Just as PPP carries all of your IP traffic (any protocol) between your home and your ISP, a PPP over SSH tunnel will also carry whatever you need it to.
For those that would die defending it, Freedom
has a sweet taste that the protected will never know.
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)
Why would you want to do that? Not only will it slow down your network connection, but I suspect that it should be fairly easy to do traffic analysis to determine which traffic was yours in the first place, even at a busy ISP...
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.