Bug 1081804

Hi Christopher,

thanks for the report. I was aware of broken IPsec in OpenVZ but I never found time to gather more information. Will the kernel-libipsec be automatically used in OpenVZ guests? Which platforms are supported, by the way?

Cheers,

Pavel

(In reply to Pavel Šimerda (pavlix) from comment #1)
> Hi Christopher,
> 
> thanks for the report. I was aware of broken IPsec in OpenVZ but I never
> found time to gather more information. Will the kernel-libipsec be
> automatically used in OpenVZ guests? Which platforms are supported, by the
> way?
> 
> Cheers,
> 
> Pavel

You can take a look at the reference:

http://wiki.strongswan.org/projects/strongswan/wiki/Kernel-libipsec

I haven't taken exhaustive research, but it works(I can confirm on iOS device of Cisco IKE provided by strongswan).

OpenVZ also said:

https://openvz.org/IPsec

* Kernel 042stab084.8 or later

* The following kernel modules must be loaded before container start:
af_key esp4 esp6 xfrm4_mode_tunnel xfrm6_mode_tunnel

* Capability net_admin must be granted to a container

But it used libreswan to test in the last year.

Which platform? What do you mean? Not Linux?

(In reply to Christopher Meng from comment #2)
> (In reply to Pavel Šimerda (pavlix) from comment #1)
> > Hi Christopher,
> > 
> > thanks for the report. I was aware of broken IPsec in OpenVZ but I never
> > found time to gather more information. Will the kernel-libipsec be
> > automatically used in OpenVZ guests? Which platforms are supported, by the
> > way?
> > 
> > Cheers,
> > 
> > Pavel
> 
> You can take a look at the reference:
> 
> http://wiki.strongswan.org/projects/strongswan/wiki/Kernel-libipsec

It doesn't seem to specify whether it gets used by default or not. The plugin seems to have a lot of limitations and it would be an unwanted change in behavior if tun was now used instead of the kernel ipsec stack.

> I haven't taken exhaustive research, but it works(I can confirm on iOS
> device of Cisco IKE provided by strongswan).
> 
> OpenVZ also said:
> 
> https://openvz.org/IPsec
> 
> * Kernel 042stab084.8 or later
> 
> * The following kernel modules must be loaded before container start:
> af_key esp4 esp6 xfrm4_mode_tunnel xfrm6_mode_tunnel

I thought the whole point of the libipsec plugin was to avoid the need for those kernel modules.

> * Capability net_admin must be granted to a container

Not sure if I had all of those enabled, but I tried ipsec transport mode on OpenVZ a long time ago and both the policy and the keys seemed to be installed in the kernel but the traffic didn't get through.

> But it used libreswan to test in the last year.

And did it work? My impression was that the problem is not in userspace.

> Which platform? What do you mean? Not Linux?

Yep, was just curious.

I would like to get more information here or close the ticket.

(In reply to Pavel Šimerda (pavlix) from comment #4)
> I would like to get more information here or close the ticket.

I'm afraid I can't provide any more info here. It maybe helpful if we can get some info from upstream...

As requested some information from upstream.

> > You can take a look at the reference:
> > 
> > http://wiki.strongswan.org/projects/strongswan/wiki/Kernel-libipsec
> 
> It doesn't seem to specify whether it gets used by default or not. The
> plugin seems to have a lot of limitations and it would be an unwanted change
> in behavior if tun was now used instead of the kernel ipsec stack.

Whether the plugin gets used or not depends on the plugin load order.  Basically the first plugin that provides an IPsec backend gets used.  For Linux choices are kernel-netlink (the default), kernel-pfkey and kernel-libipsec.  Because the kernel-netlink plugin is always required on Linux (because it also provides a network backend) the kernel-libipsec plugin is listed before all other kernel plugins in the default plugin list.  This way its IPsec backend is used and the kernel-netlink plugin only provides the networking backend.  So without further measures, that is, if the kernel-libipsec plugin is simply enabled and packaged, the libipsec IPsec implementation would get used.  Therefore if you consider providing the plugin I would definitely recommend to either disable it by default via its load option (in /etc/strongswan.d/charon/kernel-libipsec.conf), or provide it in a separate and optional package (together with that config file).

> > * The following kernel modules must be loaded before container start:
> > af_key esp4 esp6 xfrm4_mode_tunnel xfrm6_mode_tunnel
> 
> I thought the whole point of the libipsec plugin was to avoid the need for
> those kernel modules.

Exactly, those are not needed when kernel-libipsec is used.

Hi Tobias,

thanks a lot for the valuable information. One more question, if kernel-netlink is required anyway, does the kernel-libipsec actually help in container setups?

Hi Christopher,

with the information from Tobias it looks like we should only ship kernel-libipsec in a subpackage and let container users install it explicitly. Is that acceptable for you? Are you willing to make that change in the Fedora master (rawhide) dist-git branch?

Cheers,

Pavel

Hi Pavel,

> One more question, if kernel-netlink is required anyway, does the
> kernel-libipsec actually help in container setups?

With the kernel-libipsec plugin enabled (and loaded before the kernel-netlink plugin) only the networking backend of kernel-netlink is used (to enumerate/install routes/IPs etc.), which doesn't require the XFRM/IPsec kernel modules.  So this should work fine in container setups.

Regards,
Tobias

Thanks, Tobias.

(In reply to Pavel Šimerda (pavlix) from comment #9)
> Thanks, Tobias.

Can't we package and use configuration file to mark the plugin as disabled by default instead of introducing more subpkgs? I don't think users will notice this change when simply "yum install strongswan". And to me less packages means less operation.

(In reply to Christopher Meng from comment #10)
> (In reply to Pavel Šimerda (pavlix) from comment #9)
> > Thanks, Tobias.
> 
> Can't we package and use configuration file to mark the plugin as disabled
> by default instead of introducing more subpkgs?

It's possible as well but the idea of enabling it by default but not shipping the module by default sounds good to me. You could then install "strongswan" on normal hosts and "strongswan-libipsec" in containers. It's so much easier to integrate with installation tools like kickstart where you just choose the right packages to be included.

Of course you might say that explicit is better than implicit, so I'm ok with any setup that allows you to use strongswan-libipsec as long as it doesn't change the default behavior. Also, if you wanted to modify the default configuration files,
I would be much more happy if that happens upstream rather than specifically for Fedora.

> And to me less packages means less operation.

Subpackages are easy to deal with in Fedora, so I don't think it adds any maintainance burden. And administrators would have to perform some explicit action to use libipsec anyway.

Fixed by creating a subpackage called strongswan-libipsec. I hope this change won't affect behavior of the basic strongswan package in any way.

OK. 

Thanks, I hope all Fedora and EPEL6+ branch will receive the update.