From: Alexander Samad <alex@samad.com.au>
To: Netfilter <netfilter@lists.netfilter.org>
Subject: Re: vpn under linux
Date: Sun, 11 Apr 2004 09:41:27 +1000 [thread overview]
Message-ID: <20040410234127.GD14988@samad.com.au> (raw)
In-Reply-To: <200404101100.25648.Antony@Soft-Solutions.co.uk>
[-- Attachment #1: Type: text/plain, Size: 2044 bytes --]
On Sat, Apr 10, 2004 at 11:00:25AM +0100, Antony Stone wrote:
> On Saturday 10 April 2004 10:41 am, Gianni Pucciani wrote:
>
> > Hi,
> > I forget one things, waht about the CIPE solution. I read that in the
> > rh9 sec guide about VPN.
>
> Yes, I should have mentioned that. It uses a different method for encrypting
> the data than IPsec does (Blowfish instead of 3DES) and is therefore supposed
> to be faster. However in my experience you need to have a *big* pipe to the
> outside world in order to be encrypting so much data down your VPN that a
> basic CPU can't handle it.
>
> I've never used CIPE so can't comment on it in practice.
>
> I tend to use the standard which is supported by most other vendors for
> cross-compatibility, therefore I like IPsec.
>
> > And then, I see this news: the FreeS/WAN project is no longer in
> > active development, it could be a problem?
>
> I don't regard it as a problem - I think people will continue to use the
> latest version for setting up IPsec with Linux 2.4 kernels, and they'll
> migrate to using the built-in IPsec for 2.6 kernels.
>
> The main reason that FreeS/WAN is no longer being developed is because
> although it works well as a VPN, the team don't think they can achieve one of
> their goals, which was Opportunistic Encryption (using DNS to hold public
> keys so that routers could create VPN tunnels on their own when they wanted
> to talk to each other, instead of being manually configured to set up
> specific tunnels).
>
> In my opinion that doesn't stop it still being very useful as a way to
> configure standard IPsec links.
Development has moved to openswan
>
> Regards,
>
> Antony.
>
> --
> The difference between theory and practice is that in theory there is no
> difference, whereas in practice there is.
>
> Please reply to the list;
> please don't CC me.
>
>
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-04-10 23:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-10 9:01 vpn under linux Gianni Pucciani
2004-04-10 9:18 ` Antony Stone
2004-04-10 9:31 ` Gianni Pucciani
2004-04-10 9:44 ` Antony Stone
2004-04-10 9:41 ` Gianni Pucciani
2004-04-10 10:00 ` Antony Stone
2004-04-10 10:15 ` Gianni Pucciani
2004-04-10 23:41 ` Alexander Samad [this message]
2004-04-11 0:09 ` Aaron P. Martinez
2004-04-12 12:25 ` Scott MacKay
2004-04-12 16:01 ` John A. Sullivan III
2004-04-12 18:58 ` Dick St.Peters
2004-04-10 9:47 ` Victor Julien
2004-04-10 12:30 ` John A. Sullivan III
2004-04-10 17:23 ` Tony Earnshaw
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040410234127.GD14988@samad.com.au \
--to=alex@samad.com.au \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.