Bug 1213650 - "received HASH payload does not match" after updating Strongswan from 5.2.0-4.fc21 to 5.2.2-2.fc21
Summary: "received HASH payload does not match" after updating Strongswan from 5.2.0-4...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: strongswan
Version: 21
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Pavel Šimerda (pavlix)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-21 02:09 UTC by Kristian McColm
Modified: 2015-10-30 20:04 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-09 09:31:57 UTC
Type: Bug


Attachments (Terms of Use)

Description Kristian McColm 2015-04-21 02:09:50 UTC
Description of problem:
On yum update I received an update to Strongswan from 5.2.0-4.fc21 to 5.2.2-2.fc21 after restarting noticed that IPSec tunnel no longer comes up. After rollback to previous version and reapply other yum updates excluding Strongswan the issue is resolved.

Version-Release number of selected component (if applicable):
5.2.2-2.fc21

How reproducible:
Always

Steps to Reproduce:
1. Upgrade to Strongswan 5.2.2-2.fc21 with 'yum udpate'
2. Try to establish IPSec PSK VPN without changing configuration
3. Observe message "received HASH payload does not match" and failure of the IPSec tunnel to come up.

Actual results:
IPSec tunnel fails to come up

Expected results:
IPSec tunnel comes up

Additional info:
Apr 20 21:43:49 gw charon-custom: 15[ENC] parsed QUICK_MODE request 3216151474 [ HASH SA No ID ID ]
Apr 20 21:43:49 gw charon-custom: 15[IKE] Hash(3) => 20 bytes @ 0x7f58c80043f0
Apr 20 21:43:49 gw charon-custom: 15[IKE]    0: 2A 6B F1 7A 65 AF 10 B1 48 9B B2 C1 43 E0 38 B4  *k.ze...H...C.8.
Apr 20 21:43:49 gw charon-custom: 15[IKE]   16: F9 92 36 84                                      ..6.
Apr 20 21:43:49 gw charon-custom: 15[ENC] HASH received => 20 bytes @ 0x7f58c8002430
Apr 20 21:43:49 gw charon-custom: 15[ENC]    0: A9 A9 91 05 41 6C 26 11 9C 0F FB 8C 5D 00 81 DA  ....Al&.....]...
Apr 20 21:43:49 gw charon-custom: 15[ENC]   16: D6 CA 20 0F                                      .. .
Apr 20 21:43:49 gw charon-custom: 15[ENC] HASH expected => 20 bytes @ 0x7f58c80043f0
Apr 20 21:43:49 gw charon-custom: 15[ENC]    0: 2A 6B F1 7A 65 AF 10 B1 48 9B B2 C1 43 E0 38 B4  *k.ze...H...C.8.
Apr 20 21:43:49 gw charon-custom: 15[ENC]   16: F9 92 36 84                                      ..6.
Apr 20 21:43:49 gw charon-custom: 15[ENC] received HASH payload does not match
Apr 20 21:43:49 gw charon-custom: 15[IKE] integrity check failed
Apr 20 21:43:49 gw charon-custom: 15[ENC] added payload of type NOTIFY_V1 to message
Apr 20 21:43:49 gw charon-custom: 15[ENC] order payloads in message
Apr 20 21:43:49 gw charon-custom: 15[ENC] added payload of type NOTIFY_V1 to message
Apr 20 21:43:49 gw charon-custom: 15[IKE] Hash => 20 bytes @ 0x7f58c8004b30
Apr 20 21:43:49 gw charon-custom: 15[IKE]    0: E2 A5 EF 67 BD 8D 86 BF E4 3C 2A 39 E2 51 E4 50  ...g.....<*9.Q.P
Apr 20 21:43:49 gw charon-custom: 15[IKE]   16: 3B C7 DE 9A                                      ;...
Apr 20 21:43:49 gw charon-custom: 15[ENC] generating INFORMATIONAL_V1 request 2221307331 [ HASH N(INVAL_HASH) ]

Comment 1 Pavel Šimerda (pavlix) 2015-06-05 08:29:06 UTC
Hi,

strongswan as a package is pretty new in Fedora and so far it worked well to handle all issues including security ones by updating the upstream package for all supported Fedora versions.

I do not see any significant changes between upstream 5.2.0 and 5.2.2 regarding HASH payload. It might be useful to bring the issue upstream and provide them with enough configuration information. Apart from upstream changes, we changed the configure options.

See also:

 * https://wiki.strongswan.org/issues/501 (older issue, same symptoms)
 * https://www.mail-archive.com/users@lists.strongswan.org/msg06064.html (likewise)

Comment 2 Pavel Šimerda (pavlix) 2015-06-09 09:31:57 UTC
I recognize there is a reported inperoperability issue between strongswan versions with equal configuration but I'm afraid we do not have the resources to fully research it in the Fedora project, sorry. Therefore I think it's more practical to close this issue as UPSTREAM. Please work with upstream to resolve the issue and let us know if it gets fixed.

Comment 3 Kristian McColm 2015-10-30 20:04:05 UTC
Posting resolution for benefit of others:

Please refer to the thread from another user with same problem in upstream list:

https://lists.strongswan.org/pipermail/users/2014-October/006871.html

TLDR; changing:

type=tunnel

to:

type=transport

in /etc/strongswan/ipsec.conf and restarting Strongswan resolves the issue.


Note You need to log in before you can comment on or make changes to this bug.