[Openswan Users] Is OpenSwan 2.6.33 supporting kernel 2.4?

[Michael H. Warfield]

Paul already answered your initial question but I have a few questions
for you...  My apologies for the length of this and it's really just
satisfying my curiosity.

On Tue, 2011-02-22 at 13:45 -0500, Yannick Koehler wrote: 
> Hi,

> I'd like to apologize in advance for my "newbie" type of question.  My
> goal is to upgrade a package that today uses FreeS/WAN 1.9.x on the
> kernel2.4 to both kernel 2.4 and 2.6 as well as to IPv6.

> Since KLIPS and NETKEY do not offer the same level of functionality
> (ipsecX interfaces for iptables, agressive mode, initial packet buffering,
> etc), I would prefer to stay with KLIPS in order to remains as close as
> comptabile as with FreeS/WAN.

Just to address a couple of points here, since I used NETKEY and support
it and I don't find functionality missing in NETKEY that's available in
KLIPS...

* I don't see where you really need the ipsecX interfaces.  IPsec is a
policy VPN and from what I've seen over and over and over again, people
think of it as a routed VPN because of those interfaces.  I see a
similar analog in using "ip" for managing policy routing and "route" for
managing routes.  Policy routing is much more powerful but most users
have an enormous difficulty wrapping their heads around the concepts of
policy routing.  The NETKEY transforms are managed by "ip xfrm" which is
pure black magic to most users and well hidden behind Openswan.

* Aggressive mode?  You lost me on that one.  I'm confused about what
you are talking about.  First off, aggressive mode has to do with the
IKE key negotiations, not IPsec.  So that would be in pluto, not in
KLIPS or NETKEY.  Is there something missing in pluto that is not
working in aggressive mode that is working in KLIPS?  That relates to
some of the Cisco stuff I was working on back in the 2.6.26 area.  If
there is something missing, I would think that would be a bug in pluto
that needs addressing.  I think if you hadn't made this point, I
wouldn't have even replied.

* Initial packet buffering also has me confused but purely because I'm
not familiar with what you are referring to.  Could you or someone
elaborate on that?

Now...  All that being said.  There are some niggles I would concede on.

Trying to tcpdump or wireshark ipsec traffic is a bit ambiguous,
confusing, and unfortunately incomplete.  With KLIPS you have the
encrypted packets on the ipsecX interface and the unencrypted packets on
the normal interface.  With NETKEY, they're all should be on the normal
interface.  I've heard some complaints about that but I would argue
that's where they really should be.  We can have philosophical debates
on that point.  What IS a problem (for some) is that they are not all
there.  I think it's either the encrypted received packet or the
unencrypted received packet which is missing.  Personally, I feel this
is a bug and I know it has to do with the fact that the transform logic
merely de-encapsulates the packet and drops it back directly in-line
in-stream in the kernel without rebuffering so it never passes the dump
hook twice.  They don't consider it a significant enough problem to fix
where the fix would make their code less elegant.  Doesn't impact the
transmit chain because they have to rebuffer and requeue the
encapsulated packet so it's not as purely and in-line operation and you
can catch both with the one hook.

The other niggle is that you really have to know what you are doing in
netfilter with iptables.  You can't just rely on using the ipsec+
interfaces for discriminating between tunneled traffic and normal
traffic.  But that's all stuff that can be handled by addresses anyways.
It does mean you have to just about duplicate the policies from your
connections into your firewall rules but that doesn't seem like a bad
thing either since it's clearer what's going on there.  I've seen people
get burned by relying on interface definitions in iptables before as
well, even without the confusion of ipsec in the bucket.

My main reason for going with NETKEY was simply the fact that it is
integrated into the kernel in the upstream sources and well maintained.
I never need to patch or rebuild kernels just to maintain IPsec.  I only
ever need to rebuild a kernel if I'm working on my own device drivers (I
am a maintainer of one and a contributor to several others).  Granted we
can now build those modules outside of a kernel build and that makes
life easier but I still found that I lost nothing with NETKEY other than
loosing the maintenance headaches by having it all in the upstream
sources and already packaged in the distros.  I'm curious what scenarios
actually give you something real that's and advantage in KLIPS outside
of my niggles above.

> Also the 2.6.33 release seems to have added the support of IPv6 to KLIPS
> which would have been the only reason for me to switch to NETKEY.

Yes, IPv6 is vital.  I've been on globally addressible IPv6 for over a
decade and probably couldn't even do my job (or at least not nearly as
well) without it.  That is probably the primary initial reason I
abandoned KLIPS a long time ago (along with the no longer maintaining
out of tree kernel modules) and never looked back and never even missed
it.  Now that v4 has run out at ICANN and will run out at the RIRs by
the end of the year, all of a sudden everyone is talking about it and
interest in it has spiked right through the roof.  About bloody time.
Next person who complains this is happening way to fast and that we
didn't give them enough time to get ready for IPv6 is going to get
smacked.

> I tried to compiled openswan 2.6.33 with kernel 2.4.37.9 and got an error
> related to missing linux/pfkeyv2.h this seems to indicate a lack of kernel
> 2.4 support.  I would like to know if someone had worked out a kernel 2.4.x
> patch for openswan since the 2.6.33 release?


-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://lists.openswan.org/pipermail/users/attachments/20110223/6c3c2369/attachment.bin