Project

General

Profile

Bug #4178

IPsec leftsubnet changed to 0.0.0.0 with Cisco unity plugin active

Added by Chris Buechler over 4 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Normal
Category:
IPsec
Target version:
Start date:
01/05/2015
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.2.x
Affected Architecture:

Description

Under some circumstance we haven't exactly narrowed down yet, having the Cisco unity plugin enabled in strongswan causes it to replace its leftsubnet traffic selector value with 0.0.0.0/0, breaking negotiation. It's not universal to all VPNs to ASAs, but is replicable in a number of circumstances.

strongswan ends up logging the following:

Dec 29 23:08:20 fw01 charon: 13[IKE] <con22000|230> received INVALID_ID_INFORMATION error notify

With the following being logged by the ASA.

Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 0.0.0.0/0.0.0.0/0/0 local proxy 1.2.3.4/255.255.255.255/0/0 on interface outside

Bug Ermal thinks relevant to at least some degree.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718289

Associated revisions

Revision c014babd (diff)
Added by Chris Buechler about 4 years ago

Move libstrongswan-unity.so when Unity plugin is disabled so it can't modify the P2. Workaround for Ticket #4178

Revision 1ca17c45 (diff)
Added by Chris Buechler about 4 years ago

Move libstrongswan-unity.so when Unity plugin is disabled so it can't modify the P2. Workaround for Ticket #4178

Conflicts:
etc/inc/vpn.inc

Revision 2a44b0eb (diff)
Added by Renato Botelho over 3 years ago

Fix #4178:

- Stop moving unity .so file around to make it not being loaded
- Include all modules default .conf file from strongswan.d/charon
- After default files are included, define custom settings
- When unity is disabled, add a rule to make strongswan to not load it

Revision d9a17eaf (diff)
Added by Chris Buechler over 3 years ago

Switch to disabling strongswan unity plugin by default. Ticket #4178

History

#1 Updated by Jim Thompson over 4 years ago

  • Assignee set to Ermal Luçi

#2 Updated by Ermal Luçi over 4 years ago

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

#3 Updated by Chris Buechler over 4 years ago

  • Status changed from Confirmed to Feedback

strongswan 5.2.2 may fix, otherwise disabling unity plugin should work around, awaiting feedback

#4 Updated by Chris Buechler over 4 years ago

  • Assignee changed from Ermal Luçi to Chris Buechler
  • Priority changed from High to Normal
  • Target version changed from 2.2 to 2.2.1

disabling unity is confirmed to work around this issue, and will suffice for the vast majority in this situation. I'll revisit later. Associated internal ticket with details TNN-78094.

#5 Updated by Ermal Luçi over 4 years ago

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

#6 Updated by Chris Buechler over 4 years ago

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

#7 Updated by Ermal Luçi over 4 years ago

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.

#8 Updated by Brian Candler about 4 years ago

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.

#9 Updated by Chris Buechler about 4 years ago

  • Status changed from Feedback to Confirmed
  • Assignee changed from Chris Buechler to Ermal Luçi

this indeed is inadequate to fix the issue, we'll need that option to omit that plugin entirely.

#10 Updated by Brian Candler about 4 years ago

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)

#11 Updated by Chris Buechler about 4 years ago

  • Assignee changed from Ermal Luçi to Chris Buechler

working on this, testing plugin loading

#12 Updated by Chris Buechler about 4 years ago

  • Assignee changed from Chris Buechler to Ermal Luçi
  • Target version changed from 2.2.1 to 2.2.2

the plugin loading opens up quite a can of worms because of the ordering requirements and other challenges. Moving the plugin file effectively disables it without introducing a lot of other potential complications. That works around this problem for 2.2.1, we'll revisit for a long-term fix.

#13 Updated by Chris Buechler about 4 years ago

  • Target version changed from 2.2.2 to 2.2.3

#14 Updated by Ermal Luçi almost 4 years ago

  • Target version changed from 2.2.3 to 2.3

Its not something to be fixed for now.

#15 Updated by Jim Thompson over 3 years ago

  • Assignee changed from Ermal Luçi to Renato Botelho

assigned to Renato.

Post 2.3, we really need to take another look at strongswan, especially to move to vici rather than SMP.

#16 Updated by Jim Thompson over 3 years ago

  • Assignee changed from Renato Botelho to Matthew Smith

#17 Updated by Matthew Smith over 3 years ago

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.

#18 Updated by Jim Thompson over 3 years ago

  • Assignee changed from Matthew Smith to Renato Botelho

#19 Updated by Jim Thompson over 3 years ago

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

#20 Updated by Renato Botelho over 3 years ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100

#21 Updated by Chris Buechler over 3 years ago

  • Affected Version changed from 2.2 to 2.2.x

The plugin load changes are fine, good to be rid of the file moving hack. The fact that <unityplugin/> tag actually disables loading of the plugin irks me, but that's how it's always been.

Matt's earlier comments and review confirmed what I'd thought about the plugin in general. The majority don't want or need it, and it should be off by default.

Problem is the existence of the config tag disables it, and there isn't an <ipsec> tag in the default config. So this needs some logic flipping and changing of the vpn_ipsec_settings.php setting to Enable rather than Disable.

#22 Updated by Chris Buechler over 3 years ago

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.

#23 Updated by Renato Botelho over 3 years ago

  • Status changed from Feedback to Assigned

#24 Updated by Renato Botelho over 3 years ago

  • Status changed from Assigned to Feedback

#25 Updated by Renato Botelho over 3 years ago

Looks OK to me

#26 Updated by Chris Buechler over 3 years ago

  • Status changed from Feedback to Resolved

this is all good now

Also available in: Atom PDF