Welcome to Slashdot News It's funny.  Laugh. Programming Technology Toys
faq
code
awards
journals
subscribe
older stuff
rob's page
preferences
submit story
advertising
supporters
past polls
topics
about
bugs
jobs
hof

Sections

apache
Jul 23

apple
Jul 26
(4 recent)

articles
Jul 26
(33 recent)

askslashdot
Jul 25
(8 recent)

books
Jul 26
(1 recent)

bsd
Jul 22

developers
Jul 24
(2 recent)

features
Jul 18

interviews
Jul 26
(3 recent)

radio
Jun 29

science
Jul 26
(7 recent)

yro
Jul 25
(5 recent)

Building Linux Virtual Private Networks
SecurityPosted by timothy on 2002.02.27 8:30
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 Bri 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 Bri 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.

Bri Hatch (523490)
[ Preferences ]

Related Links
  • the book's official website
  • Building Linux VPNs from Fatbrain
  • book review guidelines
  • submission form
  • More on Security
  • Also by timothy
  • Book Reviews
    Slashdot's book review section is brimming with reader-submitted commentary on interesting books. Here's a sampling of recent reviews -- read below for how you can add yours to the list.

    For programmers, check out reviews of the Zope Bible, Programming Jabber and other specialized books.

    If you're just trying to manage programmers, grumpy's review of Managing Einsteins might be just what you're looking for. Meanwhile, keep the company afloat with lessons learned from The MouseDriver Chronicles and The Bombast Transcripts.

    Science buff? Read Tal Cohen's reaction to Rare Earth, and Peter Wayner on Digital Biology. Don't forget the grain of salt in Voodoo Science, either. His Dark Materials is one of the many Science Fiction titles that Slashdot readers have praised or panned for your pleasure.

    And somewhere between Sci-Fi and reality are books like Flesh and Machines, reporting from the intersection of yesterday's fiction and current technology.

    It's easy to submit your own reviews for consideration, too. Just read the Slashdot book review guidelines, and then use the web submission form.

    Update: 20020427 12:50 by timothy

    This discussion has been archived. No new comments can be posted.
    Building Linux Virtual Private Networks | Preferences | Top | 104 comments | Search Discussion
    Threshold: Save:
    The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
    Is it as good as New Riders' MySQL book? (Score:0)
    by Anonymous Coward on 2002.02.27 8:36 (#3077649)
    New Riders' MySQL book is mighty fine; if this is half as good it'll be worth reading
    [ Parent ]
    What's complicated about FreeSWAN? (Score:4, Interesting)
    by Anonymous Coward on 2002.02.27 8:39 (#3077660)
    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.
    [ Parent ]
      Re:What's complicated about FreeSWAN? (Score:5, Insightful)
      by Starship Trooper on 2002.02.27 8:49 (#3077724) Alter Relationship
      (User #523907 Info | http://www.geocities.com/tirnothy | Last Journal: 2002.06.19 20:41)
      What's complicated about FreeSWAN?

      Well, a LOT. Not if you're deeply involved technically in the project, but if you back out and take the perspective of someone who's never used a VPN, plenty.

      A lot of people don't even think about the fact that there's a separate protocol field in IP, or that people run any IP protocol but UDP or TCP. Getting 50/51 through your existing firmware firewall can be a real trick. FreeSWAN requires you to be able have the GNU Multi-Precision library installed for the crypto calculations before you compile it. Unless your distro can with FreeSWAN, you have to recompile your kernel with modifications.

      And, like many tools, there's no single graphical GUI; unlike SAMBA's excellent SWAT, there's nothing to lead you to ipsec.conf or ipsec.secrets. There's a LOT of reading to be done.

      Ok, so, for you or me, it's easy. Maybe a day of reading tops. But compare that to the commercial world where an application must install and be configured from a GUI in a few hours, and FreeSWAN is... nearly a toy. It's unusable in a business environment. As soon as you say "compile", a CTO is going to turn down your volume.

      It's cool, but don't call it uncomplicated. That's part of it's coolness (-;


      --
      --
      If you like Apple, then please press your right mouse button.
      [ Parent ]
        Re:What's complicated about FreeSWAN? (Score:3, Insightful)
        by smcavoy on 2002.02.27 9:30 (#3077979) Alter Relationship
        (User #114157 Info | http://slashdot.org/)
        I use Freeswan in a production environment. I have Embedded Linux routers using freeswan connecting to Linux boxes. They VPNs are relatively simple, 2 outgoing connections to central
        systems. I did find there was a large learning curve at the beginning, but now it takes 5 min to setup a new vpn tunnel. The systems have been extremely reliable. I've never had a problem (other than net congestion) with keeping the tunnels up. A lot of the tunnels have 80+ days of uptime. As for compiling, most modern distros include IPSec (trustix, mandrake, etc.) or there are options like Astaro. Having a CTO "turn down your volume" based on the fact that you have to compile software, doesn't say anything about the quality or reliability of the software, that's a personal decision by CTO not to use OSS. I do agree it's not point and click, and that would be nice, but to say it's unusable in a business environment is just untrue. It's not pretty but it works, and works well.
        --
        _________________
        The best defense against logic is ignorance.
        [ Parent ]
        Re:What's complicated about FreeSWAN? (Score:0)
        by Anonymous Coward on 2002.02.27 9:54 (#3078169)
        How right you are. As a system admin that has always used windows or dos. I am tring to change. I want to start using some Linux servers here, but one of the things that I want to use is free/swan. It does seem great, but as a 1 person IT department I have not found the time that I need to read and understand the documentation on swan. Do I want a GUI Heck yes. Do I still want access to the .conf file Heck yes. These problems are around a lot in the Linux community. The people that have always used linux do see it as hard and some dont want us new people to whine because it is not "dumb down", but on the other hand they want all of us to switch to it. I dont want to do away with the command line at all. I love it for a lot of what I do, but when I want to make changes or try out some new tools I dont want to have to spend 1-2 days reading ALL the docs just to know where to start. Just my 2 cents.
        Let the flames begin!!!!
        [ Parent ]
          Re:What's complicated about FreeSWAN? (Score:3, Insightful)
          by disappear (jon@lasser.org) on 2002.02.27 10:03 (#3078246) Alter Relationship
          (User #21915 Info | http://www.tux.org/~lasser/)
          one of the things that I want to use is free/swan. It does seem great, but as a 1 person IT department I have not found the time that I need to read and understand the documentation on swan. Do I want a GUI Heck yes.

          With security software in general, and VPN software in particular, that's a very, very dangerous attitude: a GUI may fool you into thinking that you understand what's going on when in reality you haven't a clue. With most software, that's not an issue, but with security software, that can compromise the very goal you're trying to achieve.

          I dont want to do away with the command line at all. I love it for a lot of what I do, but when I want to make changes or try out some new tools I dont want to have to spend 1-2 days reading ALL the docs just to know where to start.

          How many days do you want to spend cleaning up after a security incident that occurred because the GUI let you get away without spending two days reading documentation? How much time will you save in the long run if every time you save two days reading documentation you spend three days cleaning up?

          (We lose money on every item --- but we make it up in volume!)


          [ Parent ]
            Re:What's complicated about FreeSWAN? (Score:1)
            by BeNude (benude@nospam.sss.org) on 2002.02.27 16:15 (#3081147) Alter Relationship
            (User #28969 Info | http://www.sss.org/texnude)
            I would disagree with you about the usefulness of a GUI to implement VPN's or firewalls.

            First of all, a GUI interface, if it is well-designed, can provide every bit as much control over the underlying security behavior of a firewall as any command-line interface. Furthermore, a GUI allows an administrator to spend less time trying to deal with syntax, etc., and more time on building a ruleset that is secure.

            Someone who has done the reading and understands how firewalls and VPN's work will appreciate a GUI because of this.

            For those who don't fully understand how firewalls and VPN's work, a GUI at least provides a reasonable learning environment and early attempts at a ruleset will probably more secure anyhow. :)


            --
            The International NudeNet
            [ Parent ]
          IANACLB (Score:4, Interesting)
          by hey! (mattleo@treehouse.acrcorp.com) on 2002.02.27 11:21 (#3078804) Alter Relationship
          (User #33014 Info | http://slashdot.org/)
          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.

          --

          ----
          It's bad luck to be superstitious.
          [ Parent ]
        Where to get Freeswan packages for Red Hat (Score:2)
        by Nailer on 2002.02.27 15:47 (#3080965) Alter Relationship
        (User #69468 Info | http://www.cyber.com.au/)
        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 [steambaloon.com] (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.


        --
        --
        If you run Red Hat, and don't know about FreshRPMs and Apt-get [freshrpms.net], find out.
        [ Parent ]
        How stupid is the CTO? (Score:1)
        by SharpNose on 2002.02.27 16:21 (#3081178) Alter Relationship
        (User #132636 Info)
        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?"


        [ Parent ]
      Re:What's complicated about FreeSWAN? (Score:3, Interesting)
      by LWolenczak (lw@lwolenczak.net) on 2002.02.27 9:25 (#3077934) Alter Relationship
      (User #10527 Info | http://slashdot.org/)
      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
      [ Parent ]
      Re:What's complicated about FreeSWAN? (Score:3, Interesting)
      by Etyenne on 2002.02.27 10:40 (#3078498) Alter Relationship
      (User #4915 Info)
      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
      [ Parent ]
        Re:What's complicated about FreeSWAN? (Score:1)
        by pivo on 2002.02.27 11:17 (#3078772) Alter Relationship
        (User #11957 Info)
        From my understanding of FreeSWAN, it's not intended to connect many machines to a central point, for example a VPN for home manchines connected to a central office. It's intended to link offices together. So you should only have to install it on the specific machines that link those offices. If you're company's so big or disperse that you have thirty officies, then I guess you would have to recompile each kernel, though you'd be smarter to have identical machines and build the kernel once then distribute it to each machine.

        We use PPP over SSH for our home/office VPN for Linux and Solaris. It works very well and since it was originally a skunworks project, we didn't even have to get IT to open any new ports since SSH was already supported.
        [ Parent ]
      Re:What's complicated about FreeSWAN? (Score:2)
      by LinuxGeek8 on 2002.02.27 11:57 (#3079084) Alter Relationship
      (User #184023 Info | http://chaosmongers.org/)
      I am struggling for some time now to get it going, but I still do not understand how it works.
      On my end I have a linux firewall with iptables.
      And what I could not figure out is what to do with the packet filtering, do I need to accept traffic over 50/ip on the ipsec0 interface or the eth0 interface. Same question for the 500 udp/ip traffic.

      And the other part of the network is connected to a freebsd server with racoon running. That is a completely different ipsec implementation. At least for configuring it is different.

      I believe running a packet filter is quite hard if you want to do it right. You have to understand networking and just play with for a few weeks just to understand it.
      If anyone would tell me he has a secure packet filter running, but cannot explain how it works, I just cannot believe it. You just have to know what you are doing.
      Same with ipsec.
      Ipsec is not only networking, but also crypto.
      So there is more you need to know about it, and it adds extra complexity to firewalling.
      --

      --
      Help me people, this has to stop. I know everything.
      [ Parent ]
        Re:What's complicated about FreeSWAN? (Score:1)
        by pfunkmallone on 2002.02.28 14:44 (#3086925) Alter Relationship
        (User #89539 Info)
        On your eth0 interface of the firewall, you need to allow 500 udp, and 50 tcp (if you're using ESP which is default). This allows the IPSEC peers to setup the tunnel. http://www.freeswan.org/freeswan_trees/freeswan-1. 95/doc/firewall.html

        According to the FreeSwan folks, no firewalling NEEDS to be done on the ipsec0 interfaces, as all packets coming through this tunnel are already being disassembled and "cleaned-up" by freeswan itself.
        [ Parent ]
    • 1 reply beneath your current threshold.
    why? (Score:0)
    by tplayford (tom@sail - i t aly.com) on 2002.02.27 8:51 (#3077734) Alter Relationship
    (User #308405 Info | http://127.0.0.1:808...pmt5FPQQAgE/gibbon//)
    I'm sure this book is very usefull etc. But I've set up serveral internationl linux based VPN's now and it really isn't that difficult.

    I suppose this is the same for almost all computer books, easy if you know how...

    [ Parent ]
      Re:why? (Score:2, Insightful)
      by MonkeyBot on 2002.02.27 9:09 (#3077844) Alter Relationship
      (User #545313 Info)
      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.
      [ Parent ]
        Re:why? (Score:2)
        by Junta on 2002.02.27 13:10 (#3079648) Alter Relationship
        (User #36770 Info)
        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...

        [ Parent ]
        Re:why? (Score:2)
        by Pii (jedi.lightsaber@org) on 2002.02.27 13:31 (#3079810) Alter Relationship
        (User #1955 Info | http://port80.filtered.by.cox.com/)
        What do you mean, "PPP over SSH is strictly TCP?"

        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.
        --

        - Sig is a trademark of SigArms. [sigarms.com]

        [ Parent ]
      Re:why? (Score:2)
      by Bender Unit 22 (root@localhost) on 2002.02.27 12:13 (#3079206) Alter Relationship
      (User #216955 Info | http://www.johnschmidt.dk/ | Last Journal: 2002.01.11 11:07)
      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.
      --
      --------
      Trojans, not just for hiding soldiers anymore!
      [ Parent ]
    VPN hardware (Score:1, Troll)
    by pokka on 2002.02.27 9:02 (#3077793) Alter Relationship
    (User #557695 Info)
    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 [linksys.com] 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.
    [ Parent ]
      Re:VPN hardware (Score:2, Interesting)
      by Cyno on 2002.02.27 9:38 (#3078046) Alter Relationship
      (User #85911 Info)
      ...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.
      [ Parent ]
      Re:VPN hardware (Score:1)
      by starpool on 2002.02.27 19:12 (#3081956) Alter Relationship
      (User #562363 Info)
      We started out making slow progress with FreeS/WAN trying to connect to a Raptor Firewall, and thought we'd try to take the easy way out and use two Linksys VPN Routers. Bottom line: the LVRs will only allow one Class C subnet access to the tunnel. Since we have multiple subnets at 4 different locations, the LVR is disqualified, at least for now. (Maybe Linksys will add this capability to future firmware.) So we're back to FreeS/WAN and Raptor...now if I can just get that book at my local BN.
      [ Parent ]
    • 1 reply beneath your current threshold.
    What's wrong with PPTP? (Score:4, Interesting)
    by Jacco de Leeuw on 2002.02.27 9:06 (#3077826) Alter Relationship
    (User #4646 Info | http://www.jacco2.dds.nl/)
    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 [uni-freiburg.de] has written software which can crack the password in a couple of hours on a Pentium II.

    c't (Heise) [heise.de] reported about this.
    --

    Jacco
    -------
    Slashdot. Neuter that Nerd. Formats Stuff.

    [ Parent ]
      Re:What's wrong with PPTP? (Score:2, Informative)
      by Anonymous Coward on 2002.02.27 9:19 (#3077901)
      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.
      [ Parent ]
      Re:What's wrong with PPTP? (Score:3, Interesting)
      by FallLine on 2002.02.27 9:25 (#3077939) Alter Relationship
      (User #12211 Info)
      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.
      [ Parent ]
        Re:What's wrong with PPTP? (Score:0, Troll)
        by icedivr on 2002.02.27 14:44 (#3080500) Alter Relationship
        (User #168266 Info)
        If it's so insecure, why aren't people getting cracked all the time?

        Secondly, since when does hardware support a networking protocol in the absense of software? Any machine that can run 95 or 98 can run PPTP. They have pretty modest hardware requirements by today's standards.

        Thirdly, I have created multiple outbound pptp tunnels behind an ICS connection. It can be done.


        [ Parent ]
      Re:What's wrong with PPTP? (Score:3, Informative)
      by Junta on 2002.02.27 9:40 (#3078066) Alter Relationship
      (User #36770 Info)
      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..
      [ Parent ]
        Wrong: Win2K IPSEC uses L2TP for tunneling (Score:1)
        by Xenophon Fenderson, (xenophon+slashdot@irtnog.org) on 2002.02.27 11:24 (#3078826) Alter Relationship
        (User #1469 Info | http://web.irtnog.org/~xenophon/)

        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 [subgenius.com]!
        [ Parent ]
          Re:Wrong: Win2K IPSEC uses L2TP for tunneling (Score:2)
          by Junta on 2002.02.27 12:40 (#3079371) Alter Relationship
          (User #36770 Info)
          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...
          [ Parent ]
        Re:What's wrong with PPTP? (Score:2)
        by Nailer on 2002.02.27 18:37 (#3081785) Alter Relationship
        (User #69468 Info | http://www.cyber.com.au/)
        Win2k and newer (at least) include native IPSEC support that can interoperate with FreeS/WAN and such

        Excellent - do you have any documentation on how to do this?
        --
        --
        If you run Red Hat, and don't know about FreshRPMs and Apt-get [freshrpms.net], find out.
        [ Parent ]
          Re:What's wrong with PPTP? (Score:2)
          by Junta on 2002.02.27 21:41 (#3082448) Alter Relationship
          (User #36770 Info)
          http://www.freeswan.org/freeswan_trees/freeswan-1. 95/doc/interop.html
          contains some links, right now the tripod exceeded bandwidth, and that is the one with Windows interop. instructions, but I have seen it and it looks pretty solid.
          [ Parent ]
      Re:What's wrong with PPTP? (Score:2, Informative)
      by jeremiahstanley (miah@miah . o rg) on 2002.02.27 9:45 (#3078100) Alter Relationship
      (User #473105 Info | http://www.miah.org/)
      With Win2k you can get this [microsoft.com] 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 [ssh.com] 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 [freeswan.org] to use the newer ciphers. You can get that here [irrigacion.gov.ar] and if you need to use x509 certs you can get that stuff here [strongsec.com]. 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 [imdb.com].
      --

      Every so often, I like to go to the window, look up, and smile for a satellite picture. -- Stephen Wright
      [ Parent ]
      Its damn slow (Score:1)
      by moankey on 2002.02.27 10:08 (#3078275) Alter Relationship
      (User #142715 Info)
      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.
      [ Parent ]
      Re:What's wrong with PPTP? (Score:0)
      by Anonymous Coward on 2002.02.27 10:19 (#3078347)
      So, what's wrong with it then? Well, the security of PPTP apparently depends on the password. A German student [uni-freiburg.de] has written software which can crack the password in a couple of hours on a Pentium II.

      Thank god I'm not in Germany!!!!
      [ Parent ]
      Re:What's wrong with PPTP? (Score:0)
      by Anonymous Coward on 2002.02.27 10:26 (#3078396)
      You can buy PGPnet (IPsec client) in most office depots , office max, or Circuit City for $39. It has the same functionality as the NAI version.
      [ Parent ]
        PGPnet (Score:3, Informative)
        by Jacco de Leeuw on 2002.02.27 10:37 (#3078474) Alter Relationship
        (User #4646 Info | http://www.jacco2.dds.nl/)
        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?
        --

        Jacco
        -------
        Slashdot. Neuter that Nerd. Formats Stuff.

        [ Parent ]
      wireless PPTP == readable password file (Score:1)
      by nealmcb on 2002.03.01 9:59 (#3091216) Alter Relationship
      (User #125634 Info | http://bcn.boulder.co.us/~neal/)
      The Heise article is in German, but refers to the original paper which is in English [uni-freiburg.de]
      Normally, the file /etc/shadow (or /etc/password on old systems) is regarded one of the most vulnerable points of an unix system [Uni99]. If an attacker can obtain the information in this file, the system is nearly hacked. Using Microsoft's PPTP protocol, information about your passwords is not only publicly available, you also provide additional hints about the passwords, which allow to speed-up the attack by a factor of up to 2^16 .

      With this said, it is clear why we believe Microsoft's PPTP implementation isn't suitable for securing wireless networks.


      --

      --Neal
      Go IETF [ietf.org]! Go CPSR [cpsr.org]!

      [ Parent ]
    Problem is getting Management to go along (Score:2, Interesting)
    by Cy Guy on 2002.02.27 9:27 (#3077946) Alter Relationship
    (User #56083 Info | http://www.digitalri...04_affiliatesLP.html | Last Journal: 2002.05.20 18:38)
    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 [amazon.com] 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.


    --
    We ought to care less about rules & regulations [amazon.com]
    [ Parent ]
      Re:Problem is getting Management to go along (Score:0)
      by MojoReisen (jgrabowski.abm@com) on 2002.02.27 22:00 (#3082501) Alter Relationship
      (User #218327 Info)
      You've got that right.

      We're tasked with supporting Citrix IE-ALE Windows VPN clients with FlowPoint modems or Instant Internet boxes over DSL. Of course it is completely unrealiable.
      The task is truly Herculean. They (vendors)all point their fingers at each other, and I'm waist-deep in IPSec, MTU's ,etc. and all that other black magic.

      --
      --Inter caecos regnat luscus.
      [ Parent ]
    Can't beat SSH (Score:2, Insightful)
    by schlach on 2002.02.27 9:27 (#3077953) Alter Relationship
    (User #228441 Info)
    for simple encrypted forwarding

    LocalForward 8080 theproxy:8080
    LocalForward 25 thesmtp:25
    LocalForward 143 theimap:143

    Don't forget your '-g' =)
    [ Parent ]
      SSH != VPN. That's a good thing. (Score:1)
      by Bri Hatch on 2002.02.27 11:32 (#3078902)
      (User #523490 Info | http://www.ifokr.org/bri/)
      We have a section about when a VPN is not what you need, and these are the exact kind of examples when a VPN is unnecessary overkill.

      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.

      [ Parent ]
        Re:SSH != VPN. That's a good thing. (Score:2)
        by brassrat77 (brassrat77 AT yahoo DOT com) on 2002.02.27 14:33 (#3080403) Alter Relationship
        (User #9533 Info)
        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.

        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)

        [ Parent ]
    The main problem with IPSEC... (Score:5, Insightful)
    by Junta on 2002.02.27 9:48 (#3078126) Alter Relationship
    (User #36770 Info)
    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...
    [ Parent ]
      Re:The main problem with IPSEC... (Score:1, Informative)
      by Anonymous Coward on 2002.02.27 9:58 (#3078205)
      Actually, this is bypassed by disabling split tunneling (allowing the client machine to access the internet "directly" and accessing the VPN tunnel).

      -m


      [ Parent ]
        Re:The main problem with IPSEC... (Score:2)
        by j7953 on 2002.02.27 12:19 (#3079240) Alter Relationship
        (User #457666 Info)
        Actually, this is bypassed by disabling split tunneling (allowing the client machine to access the internet "directly" and accessing the VPN tunnel).

        Well, but that doesn't prevent the telecommuter's computer to become compromised with some background logging software that'll collect information when connected to the company network, and send it to the attacker when connected to the internet.

        Of course, using an SSH tunnel also doesn't solve that problem.

        The only real option is to assign IPs from a different subnet to the telecummters' home computers, and having a firewall between that subnet and the rest of the company network that'll not allow access to certain ressources that are especially critical. And, of course, the telecommuters must be educated about the security issues.


        --
        Sig (appended to the end of comments I post, 54 chars)
        [ Parent ]
      Re:The main problem with IPSEC... (Score:2, Informative)
      by icedivr on 2002.02.27 10:10 (#3078285) Alter Relationship
      (User #168266 Info)
      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.
      [ Parent ]
      Re:The main problem with IPSEC... (Score:2)
      by Shoten on 2002.02.27 10:29 (#3078417) Alter Relationship
      (User #260439 Info)
      So, you're saying the main problem with IPSEC is that it's not a magic bullet? Nothing is...get over it. I've heard people say the same about firewalls, saying how firewalls make people think that they're totally secure, so they no longer patch systems or pay attention. That may be true sometimes, but it's still not a valid argument that firewalls are flawed. Security isn't one box or one piece of software, and saying that one has a problem because it doesn't blanket everything is like criticizing deadbolts because thieves can still break a window to get into your home.

      --
      A fool and his money are soon venture capital.
      [ Parent ]
        Re:The main problem with IPSEC... (Score:2)
        by Junta on 2002.02.27 11:53 (#3079060) Alter Relationship
        (User #36770 Info)
        Right, but I was saying that IPSEC is not only not a magic bullet (that is to be expected) but companies outright misuse the technology without any serious thought. They invest tons in making sure they have tight firewalls and policies that prohibit people from hooking up modems to the outside world (internet without firewall), and yet repeat the mistake in a different form time and time again. It would be nice to establish trusted connections to telecommuters, but it just simply can never be secure enough (well, maybe if the telecommuter is the same person who designed the corporate security and takes home security equally seriously, but not worth finding out).
        [ Parent ]
          Re:The main problem with IPSEC... (Score:2)
          by Shoten on 2002.02.28 8:15 (#3084102) Alter Relationship
          (User #260439 Info)
          I see your point, but at that stage of the game, it's not the technology that is to blame. Any solid technology will be a problem if it is not part of a sound, well-thought out implementation. There are ways around the problem as well, however; for example, Checkpoint VPNs can push a security policy out to the client upon connection, enforcing a firewall policy at the end point and prohibiting network communications between that point and any node besides the VPN gateway. But that's a whole other ball of wax, and returns to the issue of making wise choices when rolling out technology.

          The bottom line is, VPNs make it possible to do things in business that aren't cost-effective any other way, and businesses are there to make money, not to be secure. It's a trade-off, and if the return outweighs the risk, it's worth the risk.

          --
          A fool and his money are soon venture capital.

          [ Parent ]
      Re:The main problem with IPSEC... (Score:1)
      by Sloppy on 2002.02.27 10:59 (#3078631) Alter Relationship
      (User #14984 Info | http://slashdot.org/ | Last Journal: 2002.07.17 10:59)

      So the effectiveness of the firewall is greatly reduced

      Don't you have the same exact problem with desktop machines on the LAN, inside the firewall? Seems to me that VPN-though-a-firewall doesn't introduce any vulnerabilities that you don't already have.


      --
      "Oh no, 3 horny women and only 2 condoms...Thank god I read slashdot" -- Anonymous Coward
      [ Parent ]
        Re:The main problem with IPSEC... (Score:0)
        by Anonymous Coward on 2002.02.27 11:38 (#3078946)
        But LAN machines have never been exposed to the internet. I am sure somebody can put some "fun" deamons up on a machine just waiting for a VPN connection.
        [ Parent ]
          Re:The main problem with IPSEC... (Score:1)
          by Sloppy on 2002.02.27 12:18 (#3079239) Alter Relationship
          (User #14984 Info | http://slashdot.org/ | Last Journal: 2002.07.17 10:59)

          But LAN machines have never been exposed to the internet.

          Ha hah hah ha! That's a good one.

          Seriously, it must be nice to work at a place where they haven't heard of "Active Content" and no one uses products like Microsoft Word or Microsoft Outlook. :-)


          --
          "Oh no, 3 horny women and only 2 condoms...Thank god I read slashdot" -- Anonymous Coward
          [ Parent ]
            Re:The main problem with IPSEC... (Score:2)
            by Junta on 2002.02.27 12:48 (#3079450) Alter Relationship
            (User #36770 Info)
            When dealing with internal systems, you can enforce all kinds of policies about virus software, etc. You can keep it relatively boxed. With telecommuting, the clients not only have relaxed restrictions, but also are vulnerable while connected to the internet to the sort of attacks firewalls are meant to keep out. Normally, this wouldn't be too bad, but with a full tunnel, that machine will probably contain sensitive information itself and, for the duration of the connection, gives full access to a corporate network if compromised.
            [ Parent ]
            Re:The main problem with IPSEC... (Score:0)
            by Anonymous Coward on 2002.02.27 14:07 (#3080140)
            If you want to get legalistic about it:

            Local Area Network by definition is not a Wide Area Network now is it? If you have a LAN you cannot be exposed to the internet or it is a WAN. If you run active content then you are running code on the LAN. Don't run unknown code on a LAN. If you downloading something from the internet you are using a WAN interface are you not?

            The point is you have a machine that has been directly exposed to the intenet and now it is on your network and that is NOT the same thing.If I have to go to the head at a bus station I will finish my drink because I won't really know what it is when I get back.
            [ Parent ]
      Re:The main problem with IPSEC... (Score:1)
      by -audiowhore- on 2002.02.27 16:08 (#3081115) Alter Relationship
      (User #153163 Info)
      Bollocks! There are quite a few commercial VPN clients out there that either have a 'stateful' firewall engine (Check Points Secure Client), and some others that support personal firewall software (the Cisco client has support for Black Ice and Zone Alarms). The Cisco client can be configured to not install or initialise *unless* the personal firewall is installed/running.

      --audiowhore
      [ Parent ]
        Re:The main problem with IPSEC... (Score:2)
        by Junta on 2002.02.27 21:22 (#3082392) Alter Relationship
        (User #36770 Info)
        But then, how do you ensure the client is using approved software if you are using a standard like IPSEC? I know, corporate policy, but if people are at home, they might try more exotic things... In any event, clients configured like this are a good way to make IPSEC *better* for telecommuting, but the safest bet is to not have full network transparency, but instead only have selected services that telecommuters need and allow only those in your preferred method of access..
        [ Parent ]
    CIPE - a better solution. (Score:3, Informative)
    by ion++ on 2002.02.27 10:18 (#3078339) Alter Relationship
    (User #134665 Info | http://www.pony.dk/)
    I'm using CIPE for linux at work. It can be found at http://sites.inka.de/sites/bigred/devel/cipe.html [sites.inka.de] or for windows at http://cipe-win32.sourceforge.net/ [sourceforge.net].
    It's a better solution [sites.inka.de] 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
    --
    Some AC: The Drunken System Administrator. "You lost your password huh? That sucks. Keep guessing!"
    [ Parent ]
      Re:CIPE - a better solution. (Score:2, Insightful)
      by ion++ on 2002.02.27 10:22 (#3078367) Alter Relationship
      (User #134665 Info | http://www.pony.dk/)
      Oh yeah, i forgot to mention that it works behind a NAT, which IPSEC has trouble with.
      Further more it works with non-static ip address. Obviously one end needs to know the ip of the other end, but thats all which is needed.

      JonB
      --
      Some AC: The Drunken System Administrator. "You lost your password huh? That sucks. Keep guessing!"
      [ Parent ]
        Re:CIPE - a better solution. (Score:1)
        by The Darkness on 2002.02.27 11:29 (#3078878) Alter Relationship
        (User #33231 Info | http://slashdot.org/)
        Oh yeah, i forgot to mention that it works behind a NAT, which IPSEC has trouble with.
        Junta already posted a valid response to this statement.

        Further more it works with non-static ip address. Obviously one end needs to know the ip of the other end, but thats all which is needed.
        FreeS/WAN works great with non-static IP addresses.

        For example:

        /etc/ipsec.conf

        conn netnet
        left=theirhost.dyn.dhs.org
        leftid=@theirhost.dyn.dhs.org
        leftsubnet=10.1.1.0/24
        right=%defaultroute
        rightid=@myhost.dyn.dhs.org
        rightsubnet=10.1.2.0/24
        leftrsasigkey=....
        rightrsasigkey=....
        authby=rsasig
        auto=start

        And in ipsec.secrets:

        @myhost.dyn.dhs.org : RSA {
        ...
        }

        I have been using a similar configuration since the release of FreeS/WAN v1.5.
        --
        --
        Signature

        [ Parent ]
      Re:CIPE - a better solution. (Score:2, Informative)
      by Junta on 2002.02.27 10:39 (#3078494) Alter Relationship
      (User #36770 Info)
      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.
      [ Parent ]
      Duh, we cover cIPe in the book. (Score:2, Informative)
      by Bri Hatch on 2002.02.27 11:40 (#3078953)
      (User #523490 Info | http://www.ifokr.org/bri/)
      Ummm, we cover cIPe in the book. Would be a pretty crappy job if we hadn't.
      [ Parent ]
    Answer? (Score:3, Funny)
    by sharkey on 2002.02.27 10:29 (#3078412) Alter Relationship
    (User #16670 Info)
    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.
    [ Parent ]
    Crossplatform aspect? (Score:2, Interesting)
    by egghat on 2002.02.27 10:51 (#3078571) Alter Relationship
    (User #73643 Info)
    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 incosistent", John Peel
    [ Parent ]
      Re:Crossplatform aspect? (Score:3, Informative)
      by Junta on 2002.02.27 10:53 (#3078587) Alter Relationship
      (User #36770 Info)
      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.
      [ Parent ]
      Re:Crossplatform aspect? (Score:1)
      by Bri Hatch on 2002.02.27 11:28 (#3078871)
      (User #523490 Info | http://www.ifokr.org/bri/)
      Most of the VPN topics we cover translate easily and directly to other Unix systems. Some small difference are OS specific. You don't enable ip forwarding with /proc on solaris, for example, but the software configuration, routing examples, etc, are the same.

      We discuss PPTP s.t. you can communicate with PPTP-only Windows clients. You can run IPSec software on more recent versions of Windows, however describing how to do so would probably increase the size of the book by several hundred pages, not counting the fact that we'd have lost some serious sanity in the process.

      So when cross platform == unix-like systems, this book does it for you. When cross platform == non unix, you're on your own.
      [ Parent ]
    Semi-OT: any ISPs that route a VPN connection? (Score:1)
    by Sloppy on 2002.02.27 11:06 (#3078670) Alter Relationship
    (User #14984 Info | http://slashdot.org/ | Last Journal: 2002.07.17 10:59)

    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.


    --
    "Oh no, 3 horny women and only 2 condoms...Thank god I read slashdot" -- Anonymous Coward
    [ Parent ]
      Re:Semi-OT: any ISPs that route a VPN connection? (Score:2)
      by disappear (jon@lasser.org) on 2002.02.27 14:42 (#3080488) Alter Relationship
      (User #21915 Info | http://www.tux.org/~lasser/)
      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.)

      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...


      [ Parent ]
    Has anybody used isakmpd on Linux (Score:2)
    by Chang on 2002.02.27 11:06 (#3078673) Alter Relationship
    (User #2714 Info)
    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.

    [ Parent ]
    ssh + ppp = vpn (Score:1)
    by hopeless case (christopherlmarshall@nospam.yahoo.com) on 2002.02.27 11:11 (#3078722) Alter Relationship
    (User #49791 Info | http://www.hopelesscase.com)
    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.

    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 /usr/bin/ssh -1 -o 'Batchmode yes' -t -l root $REMOTE_HOST /usr/sbin/pppd local ${REMOTE_IP}:${LOCAL_IP} 2> $tmpfile

    # 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


    [ Parent ]
      The pty-redir hack is dead. (Score:1)
      by Bri Hatch on 2002.02.27 11:20 (#3078799)
      (User #523490 Info | http://www.ifokr.org/bri/)
      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.
      [ Parent ]
        Re:The pty-redir hack is dead. (Score:1)
        by hopeless case (christopherlmarshall@nospam.yahoo.com) on 2002.02.27 13:08 (#3079628) Alter Relationship
        (User #49791 Info | http://www.hopelesscase.com)
        Thanks for the info on "-p". I didn't know about that.

        You are correct, of course, about the flaws of my scheme, but you'd be amazed how well it works for my purposes. I work from home and need to get access to my work machines through the firewall.

        USing my 128k DSL connection to the net, I can do a lot this way, including using VNC acceptably.

        I wouldn't recommend it for any production environment, but for simple things it more than fits the bill.
        [ Parent ]
      Re:ssh + ppp = vpn (Score:1)
      by hopeless case (christopherlmarshall@nospam.yahoo.com) on 2002.02.27 11:26 (#3078840) Alter Relationship
      (User #49791 Info | http://www.hopelesscase.com)
      Here's a link to a tgz file of the pty-redir source and compiled utility:

      http://www.hopelesscase.com/pty-redir.tgz

      I had to modify it to get it to work so in the interests of saving time, I'm posting it here.
      [ Parent ]
      Re:ssh + ppp = vpn (Score:4, Informative)
      by Junta on 2002.02.27 12:14 (#3079217) Alter Relationship
      (User #36770 Info)
      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...
      [ Parent ]
        Re:ssh + ppp = vpn (Score:1)
        by hopeless case (christopherlmarshall@nospam.yahoo.com) on 2002.02.27 13:10 (#3079657) Alter Relationship
        (User #49791 Info | http://www.hopelesscase.com)
        Yes, it leads to poor performance and an unstable link. Still, for my purposes (connecting from home to my work machines through a firewall over a DSL line at 128kbps), you'd be suprised how useful it is.

        IPSec would be better but I would have a lot to learn and experiment with before I could use it. The ssh+ppp solution is much easier.
        [ Parent ]
    Right in time. (Score:2)
    by Bender Unit 22 (root@localhost) on 2002.02.27 12:06 (#3079151) Alter Relationship
    (User #216955 Info | http://www.johnschmidt.dk/ | Last Journal: 2002.01.11 11:07)
    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. :)

    --
    --------
    Trojans, not just for hiding soldiers anymore!
    [ Parent ]
    Books cost $$$. (Score:1)
    by Vindicated on 2002.02.27 12:25 (#3079274) Alter Relationship
    (User #562257 Info)
    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.
    [ Parent ]
    vtun (Score:1)
    by joey2k ((moc.retnecwi) (ta) (leoj)) on 2002.02.27 15:13 (#3080725) Alter Relationship
    (User #472054 Info)
    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
    [ Parent ]
    Why FATBRAIN? (Score:1)
    by ghotiboy on 2002.02.28 9:03 (#3084488) Alter Relationship
    (User #7771 Info | http://127.0.0.1/)
    Why not use Bookpool? http://www.bookpool.com/.x/hhowgiv3a6/sm/157870266 6

    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 /.'ed too. :-)
    [ Parent ]
  • 11 replies beneath your current threshold.
  • Be careful! UGLY strikes 9 out of 10!
    All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest 1997-2002 OSDN.
    [ home | awards | contribute story | older articles | OSDN | advertise | self serve ad system | about | terms of service | privacy | faq ]