pfSense

Pushed a sysctl to be able to disable unity plugin as a workaround.

There has been some fixes on 5.2.2 related to that but not complete one.

reported here that just setting cisco_unity=no is inadequate to fix this issue.
https://forum.pfsense.org/index.php?topic=87333.0

also a Mikrotik config in that thread to replicate

Probably that was because the strongswan setting was not being propagated to the plugin.
Now that strongswan was updated to reload on cisco_unity it should be ok.

I also found that disabling the plugin is inadequate to fix the issue (even after a strongswan restart). I'm now trying removing the libstrongswan-unity.so module entirely but will need to wait to see if the problem is fixed.
http://lists.pfsense.org/pipermail/list/2015-February/008206.html

The remote end is Cisco ASA5505. The tunnel goes down intermittently and the Cisco is logging that the left subnet requested is 0.0.0.0/0.

I renamed `libstrongswan-unity.so` to `libstrongswan-unity.so.orig` three days ago, and the tunnel has stayed up all that time, so it looks like a workaround.

(Having said that, there are at least two upstream bugs here: that this module is causing negotiation of 0.0.0.0/0 sometimes, and that disabling this module doesn't actually disable its behaviour)

Adding some analysis for the sake of documentation. The ticket was assigned to me and I'm not sure exactly how much was already figured out by other people about the problem or the various complaints/symptoms observed prior to the issue being temporarily worked around. Here are some different items that were mentioned in the ticket or the cited threads and what I believe is happening for them.

Traffic selector is being changed to 0.0.0.0/0 for the pfSense side:

Based on this strongswan commit history https://github.com/strongswan/strongswan/commits/master/src/libcharon/plugins/unity/unity_narrow.c, the TS for the local side gets changed to 0.0.0.0/0 because cisco and shrew clients expect and require that. I am inferring that those clients want the TS to be 0.0.0.0/0 initially and it can be updated by the split-include and split-exclude subsequently. The unity plugin seems designed to support a client/server scenario (where the above makes some sense), rather than as a peer-to-peer config. People mentioned that they were seeing this behavior on Mikrotik RouterOS and Cisco ASA connected in a peer-to-peer config. They probably have some support for a subset of the unity functionality for some particular case (e.g. it was mentioned that RouterOS supports split-include, the ASA may have support for unity in order to act as a VPN server). Its unlikely that it is appropriate or necessary in most peer-to-peer scenarios to send cisco unity attributes, especially in the way that the unity plugin does it. The unity plugin should be disabled by default and can be enabled if a user chooses to do so, or it can automatically be enabled for an IKEv1 mobile IPsec VPN. And it should be noted that enabling it for a mobile IPsec VPN may cause the problems described here for peer-to-peer tunnels configured on the same pfSense instance.

"Disable Unity Plugin" doesn't fix the problem (and doesn't actually keep the plugin from loading):

The setting of cisco_unity = no just prevents the payload from being sent that indicates to the peer that unity is supported. It doesn't keep the plugin from loading or working. We can keep the module from being loaded by either configuring the explicit list of modules to load in strongswan.conf ( charon.load = plugin1 plugin2 ....) or by setting charon.load_modular = yes and charon.plugins.unity.load = no. The workaround that was put in place kept charon from finding the shared object for the unity plugin by renaming it. That works for now but we should figure out which of the other two solutions works better. When we move to a packaged install, we won't want to keep moving installed files around.

please discuss with matt the effect of load=NO in the unity config file, and implement as necessary.

what I just pushed should cover the last of this. Now disabled by default. Upon upgrade, any systems with it set to disabled have that config tag removed so it's still disabled. Systems with it enabled will have it disabled upon upgrade, which will be fine for nearly everyone. No way to tell which systems should actually have it enabled with certainty, so will just have to be a note added to the release notes that it's been disabled and needs to be enabled for anyone requiring it.

Looks OK to me