While we're on this topic... I'm tyring to get PoPToP running on my work
machine, and failing (maybe). I guess the real problem is client-side --
the documentation on how to set up the pptp client is sparse at best (the
entire "USING" file is 19 lines long, and amazingly uninformative). Maybe
I'm just lacking the experience that would make it all obvious, but when I
try to kick off pptp, I use:
pptp ip.address.of.host
and it seems to work -- pppd gets kicked off, happy things are said... but
ppp0 never comes up, nor gets an IP, and finally dies with
LCP: timeout sending Config-Requests
Then, when I try to kick it off to try some other command-line syntax, I
get:
warn[open_unixsock:pptp_callmgr.c:308]: Call manager for 64.65.199.186 is already
running.
lsof | grep socket
doesn't show anything apparent, and there aren't any pppd nor pptp
processes showing. Any of you VPN gurus got any pointers? (And, yes, I'm
reasonably sure that my PoPToP/pppd server is configured properly, though,
obviously, not certain. PoPToP has great documentation, though, so I'm
fairly confident; the client side, OTOH, has me grasping at straws.)
-Ken
On Sun, 26 Nov 2000, Kenneth E. Lussier wrote:
> Benjamin Scott wrote:
> [SNIP....]
> > I have heard some rumbling that FreeS/WAN, while very promising, is not
> > quite ready for prime time, even in security critical areas. Anyone have any
> > comments on this? I have not played with FreeS/WAN yet, myself, and the
> > rumbling I have heard was just in public Internet discussion formus, so I
> > cannot exactly call it reliable. But it was enough to make me wonder.
>
> I have used FreeS/WAN extensivly. Usually when people talk about it
> being unstable, it is because it is not an easy configuration to get
> your hands around, and if you mess up the config, you could leave a
> gaping hole. There was also a boot-time encryption hole (which existed
> in 1.3 and earlier) where the network was vulnerable before FS was
> started. That hole could always be fixed by starting proper firewall
> before starting FS.
>
> There was also a flaw in the authentication keying in 1.3 and earlier
> where the gey generation exludied the prepending of "0x" to the public
> key. However, this bug increased the security of the system because it
> simply didn't allow *any* connections ;-)
>
> I have tested the encryption, stability, and general security in FS
> v1.5, and everything has always been secure.
>
> > Also: Anyone have experience connecting a Windows client with a dynamic IP
> > to a Linux-based FreeS/WAN host? Preferably with Open Source, or at least
> > free (gratis) or cheap, software?
>
> Can't be done. There are only a handful of products for Windoze that can
> do IPSEC, and even fewer that support IKE and Pluto (which are essential
> for interaction with FreeS/WAN). All of these products are commercial
> (PGPNet, F-Secure client, and InterGate). The Freeware versions of these
> products don't work because they don't support tunnel mode. There are
> problems with the commercial versions, as well. There are a set of
> scripts written by Kai Matrtius (one of the developers) that you need to
> use to extract the keys from the "keyrings" and then separate the actual
> keys from the binary garbage needed for Windows.
>
> > > There is also PoPToP (http://www.moretonbay.com/vpn or
> > > http://poptop.lineo.com), which is a pptp implimentation for Linux
> > > (Without the M$ extensions and embracements).
> >
> > Actually, PoPToP is designed specifically to *include* the MS extensions and
> > embracements. PPTP is largely a Microsoft protocol, anyway. :-(
>
> PoPToP only includes the MS extensions if you allow it to. You can
> actually set it up so that MS clients can't even connect. This is not
> the default, of course, but it can be done.
>
> > > [PoPToP] can use 128-bit rc4 encryption (not all that great, but OK)
> >
> > Ummm, I believe conventional wisdom says that with modern algorithms, session
> > encryption keys longer then 100 bits or so is just a waste of resources. In
> > fact, I just checked, and the FreeS/WAN website makes reference to this.
>
> I wasn't refering to the key length, here, I was refering to rc4. rc4 is
> considered to be one of the weaker algorhythms out there as compared to
> 3DES, Blofish, twofish, etc.
>
> > If, on the other hand, you are talking about *authentication* keys, well,
> > PPTP does not use PPKs for authentication at all. Which is where its real
> > weakness is (assuming you have disallowed the brain damage in MSCHAPv1).
> > Passwords are patheticly weak compared to even 128-bit authentication keys.
>
> Even MSCHAPv2 has quite a bit of braindamage, but it is better. However,
> the lack of authentication keys is a major blow to the security of the
> system.
>
> > > With all of this having been said (twice now), I have one more suggestion.
> > > Don't use your firewall as a VPN box.
> >
> > While this is good advice for many, if not most, cases, it is worth making
> > the point that simply moving the VPN to another box is not a panacea. You
> > still have to punch a hole through the firewall to the VPN host, and if the
> > VPN host is compromised though that channel, the game is largely up.
>
> I fully agree with this. However, my point was not aimed completely at
> the generic concept of security. A firewall box needs to be extremely
> stable in order to do it's job. A Linux firewall (for the most part),
> uses IPChains, which is kernel based, and uses primarily the CPU to
> process packets. Now, if you add a VPN system on top of that, you are
> pushing the CPU even harder. This is not to say that todays CPU
> technology can't handle it, but imagine if, you will, this scenario:
>
> The box: a PIII 600MHz system, 256MB RAM, yadda yadda yadda..... A good
> system. Using a moderate IPChains script, port-forwarding, NAT, etc. And
> let's say that there are about 1000 hits to the firewall per hour (not
> counting port-scans and other enomolies). This is a fairly stable
> system. Traffic flows well. No real bottlenecks. Now, on top of that we
> add FreeS/WAN. Since we want FS to be secure, we use RSA (`CUZ WE
> CAN!!!!!) 4096-bit authentication keys, rekey the session keys every 15
> minutes, and let's say that you have 5 simultanious tunnels per
> connection (this is actually a low number of tunnels per connection).
> You have just multiplied your CPU usage 12x.
>
> Now, this doesn't make the box insecure, but under heavier traffic, it
> could become unstable. It introduces a bottleneck on the firewall, where
> you probably don't it. Also, if the system goes down because of the
> load, then the one route out of the network is down.
>
> > There is a far too common attitude that simply by placing things behind a
> > firewall, you are secure. That is bogus. Most exploits are made possible by
> > bugs or mis-configurations in network software. You must want to use at least
> > *some* of that software, or you would not be using a firewall (you just
> > wouldn't connect to the Internet in the first place). Such bugs can be
> > exploited just as well through a firewall.
>
> This is 100% true. If the service is exploitable, it's exploitable no
> amtter where is is, as long as the service is available.
>
> > Which is not to say that this makes Kenny's advise invalid; it doesn't.
> > Just remember that there are no easy solutions to any security problem.
>
> I disagree. The are no remote *OR* local exploits for an abacus ;-)
>
> **********************************************************
> To unsubscribe from this list, send mail to
> [EMAIL PROTECTED] with the following text in the
> *body* (*not* the subject line) of the letter:
> unsubscribe gnhlug
> **********************************************************
>
>
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
