[Openswan Users] ipsec devices

[richard lucassen]

On Sat, 18 Sep 2004 11:22:37 -0500 (CDT)
Nate Carlson <natecars at natecarlson.com> wrote:

> On Sat, 18 Sep 2004, richard lucassen wrote:
> > I use native kernel-2.6-ipsec now, but I really miss my ipsecX
> > devices. As far as I understand from a quick scan of the docs I get
> > these devices back when switching to openswan. Right or wrong?
> 
> If you compile KLIPS on 2.4 or 2.6, then yes, you will get the devices
> back. Openswan can also work with the native stack; if you use it in
> that way, you will not have ipsecX devices. To get KLIPS working on
> 2.6, you do need to run Openswan CVS HEAD, and it still does not
> support NAT Traversal. Michael says it's a pretty simple patch to get
> it working, but has not had time as of yet.

Openswan with the native stack does not provide advantages though.
And AFAIK compiling KLIPS needs kernel patching, doesn't it?

> > I want to use these devices to do some QoS. I suppose that is
> > possible. Right or wrong?
> 
> What type of QoS?

tc with TBF
 
> Using KLIPS intead of the native stack, all the packets are on a
> separate interface, and you can see all of the encrypted packets. So,
> you should be able to do whatever type of QoS you want. I would
> imagine there is also a way to do this with the native stack, though.

I really wonder why the developers of the native 2.6 stack did not
implement the virtual devices. I know that for the working of IPSEC
there is no need for these devices, but having them is very comfortable
;-)

> > I use native kernel-2.6 ipsec for multiple tunnels to SonicWall 
> > appliances (ESP, 3DES, HMAC, SHA1 with shared key). Can I run into 
> > problems when switching to openswan?
> 
> Should be just fine.
> 
> > Are there any disadvantages (or problems that may occur) using
> > openswan when switching from native ipsec?
> 
> Depends on who you ask.  :)  I still prefer having the ipsecX
> interfaces around, so I haven't used the native stack enough to be
> able to tell you any advantages. Herbert will likely post some of the
> advantages of the native stack that I'm not aware of.

All I know for now is that the native stack works very well. But I miss
the virtual devices (QoS, routing, tcpdumping ;-)

Richard.