IKEv2 VPN connections fail to use DNS servers provided by the server

Bug #1772705 reported by Alexander Lochmann on 2018-05-22
104
This bug affects 16 people
Affects Status Importance Assigned to Milestone
strongswan (CentOS)
Unknown
Unknown
strongswan (Ubuntu)
Medium
Unassigned
Bionic
High
Unassigned

Bug Description

[Impact]

 * Due to a rework of libnm-glib to libnm there was an error in the
   strongswan code. This error lead to pass garbadge (pointer instead of
   string) to the parser that pushes new config to NM on connection.

 * Upstream had a fix for quite a while, it already is in Ubuntu since
   Cosmic. But we should also backport it to Bionic.

[Test Case]

 * The test follows 4 rough steps, comment #15 has details about them
   0. prep a VPN server/client setup with IKEv2
   1. Install test system
   2. Make sure you have installed strongswan-nm
   3. Setup a strongswan connection in NM GUI

[Regression Potential]

 * Compared to accessing almost random data the new code seems much safer.
   But let us be strict and anticipate regressions, I think in a setup
   that was used to get "no valid" DNS carried over it might now actually
   get proper DNS which might change name resolution for those clients.
   I doubt this is too much of an issue, as the wrong DNS before would
   already have added a delay forcing the user to debug and workaround,
   but that is the one regression that comes to mind.
 * This change only affects charon-nm which means
   a) not the strongswan server
   b) no systemd-networkd setups
   c) no setups that didn't use the NM plugin

[Other Info]

 * n/a

---

Description: Ubuntu 18.04 LTS
Release: 18.04

strongswan-nm:
  Installed: 5.6.2-1ubuntu2
  Candidate: 5.6.2-1ubuntu2
  Version table:
 *** 5.6.2-1ubuntu2 500
        500 http://de.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
        100 /var/lib/dpkg/status

Expectation:
Strongswan should actually receive and set the DNS server properly.

What does happen:
Strongswan-nm (charon-nm) does set a random DNS server which breaks the name resolution completely.

The bug has already been reported for RedHat, and has been fixed in the strongswan upstream repo:
https://bugzilla.redhat.com/show_bug.cgi?id=1574939

Related branches

Joshua Powers (powersj) wrote :
Changed in strongswan (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium

I was about to apply the patch on merge, but realized it was already part of our April change in Debian. So just mark the changelog of the merge to fix this as well.

Changed in strongswan (Ubuntu):
status: Confirmed → In Progress
Launchpad Janitor (janitor) wrote :
Download full text (4.2 KiB)

This bug was fixed in the package strongswan - 5.6.2-2ubuntu1

---------------
strongswan (5.6.2-2ubuntu1) cosmic; urgency=medium

  * Merge with Debian unstable, closes LP: #1773814 and LP: #1772705.
    Remaining changes:
    + Clean up d/strongswan-starter.postinst: section about runlevel changes
    + Clean up d/strongswan-starter.postinst: Removed entire section on
      opportunistic encryption disabling - this was never in strongSwan and
      won't be see upstream issue #2160.
    + d/rules: Removed patching ipsec.conf on build (not using the
      debconf-managed config.)
    + d/ipsec.secrets.proto: Removed ipsec.secrets.inc reference (was
      used for debconf-managed include of private key).
    + Mass enablement of extra plugins and features to allow a user to use
      strongswan for a variety of extra use cases without having to rebuild.
      - d/control: Add required additional build-deps
      - d/control: Mention addtionally enabled plugins
      - d/rules: Enable features at configure stage
      - d/libbstrongswan-extra-plugins.install: Add plugins (so, lib, conf)
      - d/libstrongswan.install: Add plugins (so, conf)
    + d/strongswan-starter.install: Install pool feature, which is useful since
      we have attr-sql plugin enabled as well using it.
    + Add plugin kernel-libipsec to allow the use of strongswan in containers
      via this userspace implementation (please do note that this is still
      considered experimental by upstream).
      - d/libcharon-extra-plugins.install: Add kernel-libipsec components
      - d/control: List kernel-libipsec plugin at extra plugins description
      - d/p/dont-load-kernel-libipsec-plugin-by-default.patch: As
        upstream recommends to not load kernel-libipsec by default.
    + Relocate tnc plugin
     - debian/libcharon-extra-plugins.install: Drop tnc from extra plugins
     - Add new subpackage for TNC in d/strongswan-tnc-* and d/control
    + d/libstrongswan.install: Reorder conf and .so alphabetically
    + d/libstrongswan.install: Add kernel-netlink configuration files
    + Complete the disabling of libfast; This was partially accepted in Debian,
        it is no more packaging medcli and medsrv, but still builds and
        mentions it.
      - d/rules: Add --disable-fast to avoid build time and dependencies
      - d/control: Remove medcli, medsrv from package description
    + d/control: Mention mgf1 plugin which is in libstrongswan now
    + Add now built (since 5.5.1) libraries libtpmtss and nttfft to
      libstrongswan-extra-plugins (no deps from default plugins).
    + d/control, d/libcharon-{extras,standard}-plugins.install: Move charon
      plugins for the most common use cases from extra-plugins into a new
      standard-plugins package. This will allow those use cases without pulling
      in too much more plugins (a bit like the tnc package). Recommend that
      package from strongswan-libcharon.
  * Dropped Changes (no more needed after 18.04)
    + Add rm_conffile for /etc/init.d/ipsec (transition from precies had
      missed that, droppable after 18.04)
    + d/control: bump breaks/replaces from libstrongswan-extra-plugins to
      libstrongswa...

Read more...

Changed in strongswan (Ubuntu):
status: In Progress → Fix Released

I'm seeing the merge is going into cosmic. How can I request to have this fix in bionic as well?

Peter Taylor (intri) wrote :

We're still seeing this issue in Bionic, strongswan-nm 5.6.2-2ubuntu1. Are there any plans to push to Bionic? Many thanks.

Peter Taylor (intri) wrote :

Did not mean to change info type - clumsy fingers.

information type: Public → Public Security
information type: Public Security → Public
Dmitry (edim24) wrote :

Hello.
I can't install version with bugfix - 5.6.2-2ubuntu1 on Ubuntu 18.04. Because it is absent in repository.

There are only such versions:

apt-show-versions -a strongswan
strongswan:all 5.6.2-1ubuntu2.4 install ok installed
strongswan:all 5.6.2-1ubuntu2 bionic ru.archive.ubuntu.com
strongswan:all 5.6.2-1ubuntu2.3 bionic-security security.ubuntu.com
strongswan:all 5.6.2-1ubuntu2.4 bionic-updates ru.archive.ubuntu.com
No stable version
strongswan:all/bionic-updates 5.6.2-1ubuntu2.4 uptodate

Could you please add 5.6.2-2ubuntu1 to the repository?

Stuart Meek (slm-meta) wrote :

Still seeing this on Ubuntu 18.04 LTS.
Updated package is not available.

tags: added: rls-bb-incoming
Rainer Stumbaum (stumbaumr) wrote :

So is this going to be fixed in the near future?

Or should I, after trying to fix the VPN of a 18.04 user for some time yesterday, just tell them to always be on the latest instead of LTS?

Sebastien (sebago) wrote :

Do you have an estimated date on release the fix on 18.04 LTS ? it's marked rls-bb-incoming for 4 months already and there are no news since.

Georg Müller (georgmueller) wrote :

Since this bug is marked as "Fix Released", I did not find it in https://launchpad.net/ubuntu/+source/strongswan/+bugs

I only found now. 18.04 is still affected, so a "Fix Released" seams wrong here, at least for 18.04

Sean McBride (seanmcb) wrote :

I just ran into this bug also, with a fully up-to-date Ubuntu 18.04. Would be nice to have it fixed in LTS.

Bryce Harrington (bryce) on 2019-10-30
tags: added: server-next
Launchpad Janitor (janitor) wrote :

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

Changed in strongswan (Ubuntu Bionic):
status: New → Confirmed
Changed in strongswan (Ubuntu Bionic):
importance: Undecided → High

Ack to Andreas re-bumping this zo high prio.
I have a PPA [1] with a test build and a MP for review [2] up.
I need to reproduce the case to define some proper SRU verification steps.

[1]: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1772705-strongswan-charon-nm
[2]: https://code.launchpad.net/~paelzer/ubuntu/+source/strongswan/+git/strongswan/+merge/375430

Clearly, affected users might be much better off to use their own tests or setups that they can re-use for this. The following just tries to come up with something a third party could re-use to test this.

0. prep a VPN server/client setup with IKEv2
I used [1] to first get a server and client setup in two VMs.
A wrapper to get this done via uvtool is attached as test-strongswan-bug-1772705.tgz
Call it like:
$ ./test.sh bionic
Once the above is up and working continue

1. Install test system
Those above are (in my case) using server images, but for Network Manager we need a Desktop.
- Download a Bionic Desktop ISO and install it into e.g. using virt-manager
- In addition to the default make the guest part of the network that the strongswan server is in

2. Make sure you have installed strongswan-nm
$ apt install strongswan-nm

3. Setup a strongswan connection, e.g. follow [2] to do so.

The actual check, when you connect to that VPN via NM the DNS servers that will be added are total garbage. Check this via e.g.:
$ nmcli dev show | grep DNS

[1]: https://code.launchpad.net/~ubuntu-security/qa-regression-testing/+git/qa-regression-testing
[2]: https://wiki.strongswan.org/projects/strongswan/wiki/NetworkManager

description: updated

Uploaded to Bionic-unapproved waiting for the SRU Team.

Hello Alexander, or anyone else affected,

Accepted strongswan into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/strongswan/5.6.2-1ubuntu2.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in strongswan (Ubuntu Bionic):
status: Confirmed → Fix Committed
tags: added: verification-needed verification-needed-bionic

I usually try to self-verify, but this is a rather complex setup, I'd call to the real users affected by this bug to give the verification of the new build in proposed a try please.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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