the only VPN solution is not in rh

[Paul Iadonisi]

On Wed, 2003-10-22 at 16:25, Wil Cooley wrote:

[snip]

> > for the the ipsec implementation. and we don't the quality of that part 
> > of the code (that was the reason why the old kernel psace can't get into 
> > the kernel). the x509 patch still not in the mainstream freeswan which 
> > is essential for windows clients. imho it needs a year to be stable and 
> > usable.
> 
> FreeS/WAN has problems, but it does work.  I'd much rather see FreeS/WAN
> support than anything; it's standard and interoperates with lots of
> other IPSEC implementations; CIPE and OpenVPN are, AFAICT, not widely
> supported and "proprietary" (in the sense that they're non-standard and
> not even seeking standardization).  FreeS/WAN itself works well enough
> as an external module; they only problem is if you want NAT-Traversal,
> it would need a patch to the actual kernel.

  Depends on what you mean by nat traversal.  You can initiate a
connection to a FreeS/WAN server from behind a firewall fine, but you do
need to use the X.509 patch so that you can use certificates AND only
one client* behind that firewall can do key negotiation as port udp 500
needs to be reverse nat-ed to point to that client.
  Having a FreeS/Wan server* behind a firewall that you would like for
clients* to be able to connect to from outside the firewall...now that's
another story.  Then, I think you do need to modify the kernel with the
nat-traversal patches.
  FreeS/Wan does have other problems, though, the most difficult one to
solve is probably non-technical in nature: unless the policy of the
FreeS/Wan team has changed, they will not accept patches from anyone
residing the USA due to past restrictions on the export of encryption. 
That makes it very difficult for a company like Red Hat to submit
patches in the hopes that they will be incorporated in later upstream
version.  And that is one of the goals of the Fedora Project -- to
remain closer to upstream.
  Nevertheless, I'm with the proponents of *some* kind of IPSec
implementation, but for me, I'm willing to do my own packages for
FreeS/Wan for the time being.  Thankfully, it is no longer necessary to
build a custom kernel ... the kernel module can be built independently. 
And since the stock, soon to be released kernel.org 2.6 kernel has built
in ipsec, I'm willing to wait for that release, meanwhile using
FreeS/Wan.
  If anyone else is interested, I'd be willing to post my spec file for
FreeS/Wan as well as pointers to any patches.  Mine builds for RHL9, but
I haven't tried on fct3.  I don't like the way the FreeS/Wan rpms are
built on xs4all.nl, so I've done it a bit differently.  Plus, I don't
build an rpm for the kernel module ... it's only one file that I copy
into the /lib/modules tree.

* I use the terms 'client' and 'server' here relatively losely.  In
reality, IPSec peers are just that: peers.  But when one is behind a
firewall, the picture does change a bit.

-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets