Multiple PSKs with dyndns left/rightids doesn't work

Hi Jan,
I'll hopefully be looking at the merge of 5.6.1 next week which includes that fix.
Once in the latest Ubuntu release we can look at the doability of a backport.

On a first sniff test it at least applies cleanly to the code in Xenial.
That still needs to follow some process and extra testing - therefore the merge will be the next ste on this.

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

---------------
strongswan (5.6.1-2ubuntu1) bionic; urgency=medium

  * Merge with Debian unstable (LP: #1717343).
    Also fixes and issue with multiple psk's (LP: #1734207). 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.
    + Ubuntu is not using the debconf triggered private key generation
      - 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).
    + Add rm_conffile for /etc/init.d/ipsec (transition from precies had
      missed that, droppable after 18.04)
    + 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.
  * Added changes:
    + d/s...

So the final commit for this issue on 5.5.2 is [1].

Current Ubuntu releases are on
- Zesty/Artful on 5.5.1
- Xenial on 5.3.5

Purely from a "patch applies" POV this applies to all three.
But obviously the confidence that this works perfectly fine is much higher on 5.5.1 than on 5.3.5.

I have some ike psk tests that I'll use on a test build with that in Xenial.

[1]: https://git.strongswan.org/?p=strongswan.git;a=commit;h=e92d8a56b376e6964e5f1b53b2d261f167e0b166

Ok, all my tests look good, but they are rather trivial compared to some setups in the wild.
I have a ppa with what I'd like to move to proposed if confirmed at [1].

I pushed a Merge Proposal for the packaging changes and got an ack by fellow packagers.

@Jan-Otto - could you test the case with your setup - I assume you had hit the bug, so you should be good to test it.

Anyone else is invited as well to test from this ppa if it might regress something unexpectedly.

You can test right now now from the ppa [1] or soon'ish from proposed [2] - there will be an extra update by the SRU team when the latter is ready.
If you get to test from [1] before that would be even better.

[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3084
[2]: https://wiki.ubuntu.com/Testing/EnableProposed

Hello Jan-Otto, or anyone else affected,

Accepted strongswan into artful-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/strongswan/5.5.1-4ubuntu2.2 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-artful to verification-done-artful. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-artful. 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!

Hello Jan-Otto, or anyone else affected,

Accepted strongswan into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/strongswan/5.3.5-1ubuntu3.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-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. 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!

Hello Jan-Otto, or anyone else affected,

Accepted strongswan into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/strongswan/5.5.1-1ubuntu3.3 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-zesty to verification-done-zesty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-zesty. 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!

Verified with 5.3.5-1ubuntu3.5 on Xenial. Here is the testing procedure with east01 as the roadwarrior with IP 169.254.6.1 (foo.bar.org) and west01 as the concentrator with IP 169.254.6.2.

west01:

root@west01:~# grep foo /etc/hosts
169.254.6.1 foo.bar.org

root@west01:~# cat /etc/ipsec.conf
# LP: #1734207
conn lp-base
  authby=psk
  keyexchange=ikev1
  mobike=no
  type=transport
  left=169.254.6.2

conn lp-east01
  also=lp-base
  right=foo.bar.org
  <email address hidden>
  auto=add

conn lp-rw
  also=lp-base
  right=%any
  auto=add

root@west01:~# cat /etc/ipsec.secrets
169.254.6.2 @foo.bar.org : PSK "PSK-EAST01"
%any : PSK "PSK-RW"

east01:

root@east01:~# cat /etc/ipsec.conf
# LP: #1734207
conn lp-east01
  authby=psk
  keyexchange=ikev1
  mobike=no
  type=transport
  left=169.254.6.2
  right=foo.bar.org
  <email address hidden>
  auto=start

root@east01:~# cat /etc/ipsec.secrets
%any : PSK "PSK-EAST01"

When west01 uses the unpatched package (5.3.5-1ubuntu3.4), east01 is unable to connect:

root@east01:~# service strongswan restart
root@east01:~# journalctl -fu strongswan | grep -m1 malformed
Dec 20 18:10:57 east01 charon[2318]: 06[IKE] ignore malformed INFORMATIONAL request

As soon as west01 is upgraded to the patched package (5.3.5-1ubuntu3.5), east01 connects:

Verified with 5.3.5-1ubuntu3.5 on Xenial. Here is the testing procedure with east01 as the roadwarrior with IP 169.254.6.1 (foo.bar.org) and west01 as the concentrator with IP 169.254.6.2.

west01:

root@west01:~# grep foo /etc/hosts
169.254.6.1 foo.bar.org

root@west01:~# cat /etc/ipsec.conf
# LP: #1734207
conn lp-base
  authby=psk
  keyexchange=ikev1
  mobike=no
  type=transport
  left=169.254.6.2

conn lp-east01
  also=lp-base
  right=foo.bar.org
  <email address hidden>
  auto=add

conn lp-rw
  also=lp-base
  right=%any
  auto=add

root@west01:~# cat /etc/ipsec.secrets
169.254.6.2 @foo.bar.org : PSK "PSK-EAST01"
%any : PSK "PSK-RW"

east01:

root@east01:~# cat /etc/ipsec.conf
# LP: #1734207
conn lp-east01
  authby=psk
  keyexchange=ikev1
  mobike=no
  type=transport
  left=169.254.6.2
  right=foo.bar.org
  <email address hidden>
  auto=start

root@east01:~# cat /etc/ipsec.secrets
%any : PSK "PSK-EAST01"

When west01 uses the unpatched package (5.3.5-1ubuntu3.4), east01 is unable to connect:

root@east01:~# service strongswan restart
root@east01:~# journalctl -fu strongswan | grep -m1 malformed
Dec 20 18:10:57 east01 charon[2318]: 06[IKE] ignore malformed INFORMATIONAL request

As soon as west01 is upgraded to the patched package (5.3.5-1ubuntu3.5), east01 connects:

root@east01:~# service strongswan restart
root@east01:~# journalctl -u strongswan | tail
Dec 20 18:14:36 east01 charon[2543]: 06[IKE] scheduling reauthentication in 9973s
Dec 20 18:14:36 east01 charon[2543]: 06[IKE] maximum IKE_SA lifetime 10513s
Dec 20 18:14:36 east01 charon[2543]: 06[ENC] generating QUICK_MODE request 2756199350 [ HASH SA No ID ID ]
Dec 20 18:14:36 east01 charon[2543]: 06[NET] sending packet: from 169.254.6.1[500] to 169.254.6.2[500] (220 bytes)
Dec 20 18:14:36 east01 charon[2543]: 05[NET] received packet: from 169.254.6.2[500] to 169.254.6.1[500] (172 bytes)
Dec 20 18:14:36 east01 charon[25...

I've tested two other scenarios (always on Xenial):

1) IKEv1+XAUTH PSK
2) IKEv2+EAP MSCHAPv2

and both worked so no regression there.

Hi,

I had to changed my setup to workaround this issue, I'm unable to test it at this time now.

Sorry.

Thanks for the extra general regression check Simon!
And also for the documentation of the detailed tests you did.

I used that to test Artful and Zesty as well.

Files as outlined by Simon Deziel, just in my case IPs different.
Note: needs hosts file on east and west.

zesty
 169.254.6.1 => 192.168.122.226
 169.254.6.2 => 192.168.122.224

artful
 169.254.6.1 => 192.168.122.220
 169.254.6.2 => 192.168.122.228

= ZESTY =

Before Fix:
ubuntu@zesty-east:~$ sudo systemctl status strongswan
[...]
Jan 02 09:52:26 zesty-east charon[2792]: 14[NET] sending packet: from 192.168.122.226[500] to 192.168.122.224[500] (124 bytes)
Jan 02 09:52:26 zesty-east charon[2792]: 15[NET] received packet: from 192.168.122.224[500] to 192.168.122.226[500] (92 bytes)
Jan 02 09:52:26 zesty-east charon[2792]: 15[ENC] invalid HASH_V1 payload length, decryption failed?
Jan 02 09:52:26 zesty-east charon[2792]: 15[ENC] could not decrypt payloads
Jan 02 09:52:26 zesty-east charon[2792]: 15[IKE] message parsing failed
Jan 02 09:52:26 zesty-east charon[2792]: 15[IKE] ignore malformed INFORMATIONAL request
Jan 02 09:52:26 zesty-east charon[2792]: 15[IKE] INFORMATIONAL_V1 request with message ID 2973179323 processing failed

After fix is on West:
$ sudo systemctl status strongswan
[...]
Jan 02 09:56:32 zesty-east charon[2954]: 11[NET] sending packet: from 192.168.122.226[500] to 192.168.122.224[500] (220 bytes)
Jan 02 09:56:32 zesty-east charon[2954]: 12[NET] received packet: from 192.168.122.224[500] to 192.168.122.226[500] (188 bytes)
Jan 02 09:56:32 zesty-east charon[2954]: 12[ENC] parsed QUICK_MODE response 3423563956 [ HASH SA No ID ID ]
Jan 02 09:56:32 zesty-east charon[2954]: 12[IKE] CHILD_SA lp-east01{1} established with SPIs c223f7cc_i c35801f3_o and TS 192.168.122.226/32 === 1
Jan 02 09:56:32 zesty-east charon[2954]: 12[IKE] CHILD_SA lp-east01{1} established with SPIs c223f7cc_i c35801f3_o and TS 192.168.122.226/32 === 1
Jan 02 09:56:32 zesty-east charon[2954]: 12[ENC] generating QUICK_MODE request 3423563956 [ HASH ]
Jan 02 09:56:32 zesty-east charon[2954]: 12[NET] sending packet: from 192.168.122.226[500] to 192.168.122.224[500] (76 bytes

= ARTFUL =

Before Fix:
ubuntu@artful-east:~$ sudo systemctl status strongswan
[...]
Jan 02 09:53:39 artful-east charon[2004]: 10[NET] sending packet: from 192.168.122.220[500] to 192.168.122.228[500] (124 bytes)
Jan 02 09:53:39 artful-east charon[2004]: 11[NET] received packet: from 192.168.122.228[500] to 192.168.122.220[500] (92 bytes)
Jan 02 09:53:39 artful-east charon[2004]: 11[ENC] invalid HASH_V1 payload length, decryption failed?
Jan 02 09:53:39 artful-east charon[2004]: 11[ENC] could not decrypt payloads
=> Jan 02 09:53:39 artful-east charon[2004]: 11[IKE] message parsing failed
=> Jan 02 09:53:39 artful-east charon[2004]: 11[IKE] ignore malformed INFORMATIONAL request
=> Jan 02 09:53:39 artful-east charon[2004]: 11[IKE] INFORMATIONAL_V1 request with message ID 505241222 processing failed

After fix is on West:
$ sudo systemctl status strongswan
● strongswan.service - strongSwan IPsec services
[...]
Jan 02 09:56:32 artful-east charon[2138]: 11[NET] sending packet: from 192.168.122.220[500] to 192.168.122.228[500] (220 by...

This bug was fixed in the package strongswan - 5.5.1-4ubuntu2.2

---------------
strongswan (5.5.1-4ubuntu2.2) artful; urgency=medium

  * d/p/ikev1-First-do-PSK-lookups-lp1734207.patch ensure evaluation
    with resolvable hostnames selects the right PSK (LP: #1734207).

 -- Christian Ehrhardt <email address hidden> Mon, 18 Dec 2017 11:05:57 +0100

The verification of the Stable Release Update for strongswan has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package strongswan - 5.5.1-1ubuntu3.3

---------------
strongswan (5.5.1-1ubuntu3.3) zesty; urgency=medium

  * d/p/ikev1-First-do-PSK-lookups-lp1734207.patch ensure evaluation
    with resolvable hostnames selects the right PSK (LP: #1734207).

 -- Christian Ehrhardt <email address hidden> Mon, 18 Dec 2017 11:13:53 +0100

This bug was fixed in the package strongswan - 5.3.5-1ubuntu3.5

---------------
strongswan (5.3.5-1ubuntu3.5) xenial; urgency=medium

  * d/p/ikev1-First-do-PSK-lookups-lp1734207.patch ensure evaluation
    with resolvable hostnames selects the right PSK (LP: #1734207).

 -- Christian Ehrhardt <email address hidden> Mon, 18 Dec 2017 11:22:24 +0100