[Lxc-users] Couple questions regarding IPSec and LXC containers

[Michael H. Warfield]

On Tue, 2013-11-19 at 00:25 -0800, Robert Adams wrote:
> Howdy
> 
I'm adding the lxc-users list to this message just because others there
may have some additional input...

> I came across your post
> at https://lists.openswan.org/pipermail/users/2010-December/019671.html where you mention that you converted VM over to LXC containers. Did you happen to try running IPSec inside a LXC container? If so, which OS / Version / Kernel were you using at the time? 

No, I had not tried that.  Typically, I've used IPsec for large scale
tunneling and then used lighter weight VPN's such a OpenVPN for other
projects, such as IPv6 tunnel brokers.

You do raise an interesting and ironically amusing point, since I'm a
significant contributor to both the Openswan and LXC projects.

I can see multiple problems and dependencies in trying to use IPSec in
and LXC container, depending on what form and flavor of IPsec you chose
to use.  First problem, in my mind, is that it's not clear what flavor
of IPsec you are attempting to use...  You got my message off the
Openswan list but then you don't say Openswan but just say IPsec...

The major flavors of IPSec in question are:

Openswan
Strongswan
IPSec-tools (aka Racoon)
VPNC

If it's Openswan or StrongSWAN, the next question has to be which
protocol interface module are you attempting to use:

KLIPS
NetLink
MAST (You wouldn't be using this and I've never used it)

(Racoon only uses Netlink and "ip xfrm")

> I have been trying, unsuccessfully, to get IPSec installed inside a
> Ubuntu LXC container created via Docker (http://www.docker.io). While
> inside the Docker LXC container, I have tried:

Another important factor can be the kernel version you are attempting to
use for this.  Containers are in a state of flux on the kernel level
with many new features being implemented at various revision clicks.

What release of Ubuntu?
What kernel release?
> 1. Pulling from apt-get didn't work. That would have been too easy. 

Pulling what specific packages?  Openswan?  I presume so, since you
found my message from 3 years ago on the Openswan list, but there are
other options available.  You say it didn't work.  Well, what happened?
What where the errors?  What blew up?  What was seen at the other end of
the tunnel?  From personal experience, it can be a black art getting
these things set up under unusual conditions and knowing exact, precise,
errors are vital.

> 2. Then I tried downloading and installing older debian packages
> directly from OpenSwan, also didn't work. 

Yeah, I'm not familiar with those but I would not attempt to use them
(especially considering I'm a Fedora use who does not like the Debian
networking paradigm to begin with).

> 3. Finally, I've tried compiling from source. I'm still working on
> this one, but I'm having trouble figuring out all the dependencies. 

That's bound to be troubling.  I wouldn't even attempt it without a
clear understanding of why I needed to do that.
> 
> If you happen to have any experience in the area and have the time to
> share, I'd really appreciate it. Really, any tips or pointers would be
> helpful. Thanks.

Well...  If you're trying to use Openswan or StrongSWAN with Netlink,
which is the combination which I'm most familiar with, you may have
problems with Netlink and the "ip xfrm" tables.  I'm not totally sure
how well those are containerized at this point.  On one hand, they
SHOULD work.  On the other hand, many things should work that don't.

Also, you may need to preload the appropriate xfrm's and crypto modules
in the host and grant access to them in the container to make this work.
They're not all loaded by default and there's a pile to choose from.  I
don't think you want to allow the container to load and unload kernel
modules autonomously.

IPSec-tools, aka Racoon should be in the same boat as Openswan or
StrongSWAN with Netlink since it only uses "ip xfrm" for its kernel
transform manipulations.

Attempting to use older Debian packages is unlikely to work,
particularly if they are attempting to use the KLIPS module from
Openswan.  KLIPS is a kernel level IPSec module which was not accepted
into the upstream kernel source tree but has its adherents (I'm NOT one
of them).  I doubt it's been adapted for container isolation but I could
be surprised.  That applies to using Openswan and StongSWAN with KLIPS.
Even though KLIPS exports ipsec* interfaces, I strongly suspect it won't
behave properly in a container.

VPNC is a user space IPsec implementation that utilizes the tun device
much like OpenVPN and should work if you have enabled tun devices in the
container.  Others have reported some success getting OpenVPN to work
that way though, again, I have not personally tried this.  Anywhere
OpenVPN is likely to work is then likely to support VPNC IPsec tunnels.
VPNC is mostly used for setting up IPSec tunnels with XAUTH to
communicate with Cisco ASA concentrators, and I'm the author of similar
code in Openswan for doing the same there only using the Openswan and
kernel level IPsec infrastructure.
> 
> Robert Adams

I may experiment with this further as you now have my curiousity up.

> 
Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  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: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20131121/8e04c2b8/attachment.pgp>