new upstream version 5.2.2

Bug #1451091 reported by Robert Sander on 2015-05-02
This bug affects 6 people
Affects Status Importance Assigned to Milestone
strongswan (Ubuntu)

Bug Description

Debian wheezy-backports and Debian jessie contain upstream version 5.2.1 of strongswan. Please make that available on Ubuntu.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: strongswan (not installed)
ProcVersionSignature: Ubuntu 3.13.0-51.84-generic 3.13.11-ckt18
Uname: Linux 3.13.0-51-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.10
Architecture: amd64
CurrentDesktop: Unity
Date: Sat May 2 23:44:00 2015
InstallationDate: Installed on 2015-04-30 (2 days ago)
InstallationMedia: Ubuntu-Server 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.3)
SourcePackage: strongswan
UpgradeStatus: No upgrade log present (probably fresh install)

Robert Sander (gurubert) wrote :
Adolfo Jayme (fitojb) on 2015-05-03
tags: added: upgrade-software-version
Changed in strongswan (Ubuntu):
importance: Undecided → Wishlist
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in strongswan (Ubuntu):
status: New → Confirmed
Bruno Thomsen (bth-v) on 2015-06-26
summary: - new upstream version 5.2.1
+ new upstream version 5.2.2
Bruno Thomsen (bth-v) wrote :

The current version of Strongswan (5.1.2) does not work with newer versions of pfSense (Strongswan 5.3.2 based).
When using IPsec IKEv2/PSK the identity type is now prefixed leftid and rightid for better matching.
The change requires at least Strongswan 5.2.2 but newest upstream is 5.3.2.


left|rightid = <id>

Since 5.2.2 it is possible to enforce a specific identity type. For this a prefix may be used, followed by a colon (:).
If the number sign (#) follows the colon, the remaining data is interpreted as hex encoding, otherwise the string is used as-is
as the identification data. Note that this implies that no conversion is performed for non-string identities.
For example, ipv4: does not create a valid ID_IPV4_ADDR IKE identity, as it does not get converted to binary
0x0a000001. Instead, one could use ipv4:#0a000001 to get a valid identity, but just using the implicit type with automatic
conversion is usually simpler. The same applies to the ASN.1 encoded types.
The following prefixes are known: ipv4, ipv6, rfc822, email, userfqdn, fqdn, dns, asn1dn, asn1gn and keyid.
Custom type prefixes may be specified by surrounding the numerical type value with curly brackets.

> The current version of Strongswan (5.1.2) does not work with newer versions of pfSense (Strongswan 5.3.2 based).
> When using IPsec IKEv2/PSK the identity type is now prefixed leftid and rightid for better matching.

Hm, could you elaborate on that? For instance, provide example configs? At a first glance I'd say what pfSense does is wrong, as it seems to send incorrectly encoded identity payloads. As described in the man/wiki page, you can't just prefix a string with a prefix and expect that to work correctly. These prefixes are really mostly useful in special situations (e.g. to encode a FQDN as keyid).

Bruno Thomsen (bth-v) wrote :

When using PSK in pfSense you are required to select identifier type. Looking at it from a security perspective it seems better to explicit define identifier type rather then auto detect type.

Bruno Thomsen (bth-v) wrote :
Bruno Thomsen (bth-v) wrote :
Bruno Thomsen (bth-v) wrote :
Bruno Thomsen (bth-v) wrote :
Bruno Thomsen (bth-v) wrote :

I have attached an example configuration where the pfSense server leftid is configured with keyid:-prefix and therefor in unable to authenticate an IPsec connection from a client where rightid does not contain keyid:-prefix.

Thanks for the example config.

The client will encode the identity as FQDN and the server is forced to encode it as keyid (the content will be the same but the type is different). So there won't be a match. Looking at the screenshot I'm not sure how to configure a FQDN in the pfSense GUI, perhaps "Distinguished name" even though the DN in FQDN stands for "domain name". Additionally, the identity in ipsec.secrets on the server is also encoded as FQDN as the prefix is missing (should probably be reported to pfSense). Also, rightid is missing on the server, so authentication will fail anyway as the server will default to the client's IP address, which won't match the client's leftid (omnicon-59000000).

Selecting the identity type could make sense, but the identities would have to be encoded properly (e.g. parse the configured string according to the type and binary encode it, then prefix it), otherwise the result will not be what the user intended (e.g. leftid=ipv4: is not the same thing as leftid= or leftid=ipv4:#c0a80001).

Eric Heydrick (eheydrick) wrote :

Strongswan 5.3.2 is out now. What would it take to pull it in?

Simon Déziel (sdeziel) wrote :

Marking this bug as a duplicate of LP: #1535951 since Strongswan 5.3.5 should land in Xenial thus addressing the issues mentioned here.

Launchpad Janitor (janitor) wrote :
Download full text (14.3 KiB)

This bug was fixed in the package strongswan - 5.3.5-1ubuntu1

strongswan (5.3.5-1ubuntu1) xenial; urgency=medium

  * debian/{rules,control,libstrongswan-extra-plugins.install}
    Enable bliss plugin
  * debian/{rules,control,libstrongswan-extra-plugins.install}
    Enable chapoly plugin
  * debian/patches/dont-load-kernel-libipsec-plugin-by-default.patch
    Upstream suggests to not load this plugin by default as it has
    some limitations.
  * debian/patches/increase-bliss-test-timeout.patch
    Under QEMU/KVM for autopkgtest bliss test takes a bit longer then default
  * Update Apparmor profiles
    - usr.lib.ipsec.charon
      - add capability audit_write for xauth-pam (LP: #1470277)
      - add capability dac_override (needed by agent plugin)
      - allow priv dropping (LP: #1333655)
      - allow caching CRLs (LP: #1505222)
      - allow rw access to /dev/net/tun for kernel-libipsec (LP: #1309594)
    - usr.lib.ipsec.stroke
      - allow priv dropping (LP: #1333655)
      - add local include
    - usr.lib.ipsec.lookip
      - add local include
  * Merge from Debian, which includes fixes for all previous CVEs
    Fixes (LP: #1330504, #1451091, #1448870, #1470277)
    Remaining changes:
      * debian/control
        - Lower dpkg-dev to 1.16.1 from 1.16.2 to enable backporting to Precise
        - Update Maintainer for Ubuntu
        - Add build-deps
          - dh-apparmor
          - iptables-dev
          - libjson0-dev
          - libldns-dev
          - libmysqlclient-dev
          - libpcsclite-dev
          - libsoup2.4-dev
          - libtspi-dev
          - libunbound-dev
        - Drop build-deps
          - libfcgi-dev
          - clearsilver-dev
        - Create virtual packages for all strongswan-plugin-* for dist-upgrade
        - Set XS-Testsuite: autopkgtest
      * debian/rules:
        - Enforcing DEB_BUILD_OPTIONS=nostrip for library integrity checking.
        - Set TESTS_REDUCED_KEYLENGTHS to one generate smallest key-lengths in
        - Change init/systemd program name to strongswan
        - Install AppArmor profiles
        - Removed pieces on 'patching ipsec.conf' on build.
        - Enablement of features per Ubuntu current config suggested from
          upstream recommendation
        - Unpack and sort enabled features to one-per-line
        - Disable duplicheck as per

        - Disable libfast (--disable-fast):
          Requires dropping medsrv, medcli plugins which depend on libfast
        - Add configure options
        - Remove configure options:
          --enable-ha (requires special kernel)
          --enable-unit-test (unit tests run by default)
        - Drop logcheck install
      * debian/tests/*
        - Add DEP8 test for strongswan service and plugins
      * debian/strongswan-starter.strongswan.service
        - Add new systemd file instead of patching upstream
      * debian/strongswan-starter.links
        - removed, use Ubuntu systemd file instead of linking to upstream
      * debia...

Changed in strongswan (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.