Project

General

Profile

Issue #1120

invalid HASH_V1 payload length, decryption failed on last QUICK request

Added by Pieter Jordaan over 3 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Category:
interoperability
Affected version:
5.3.3
Resolution:
Fixed

Description

Hi

During an IKEv1 tunnel QUICK exchange session, each of the initiator's CHILD_SA's final hash liveliness packets fails with: invalid HASH_V1 payload length, decryption failed

The tunnel itself, however functions fine even though Strongswan doesn't install the policies or routes.

statusall reveals:

chreosistunnel:  172.30.0.143...196.34.134.31  IKEv1/2, dpddelay=120s
chreosistunnel:   local:  [54.228.251.166] uses pre-shared key authentication
chreosistunnel:   remote: [196.34.134.31] uses pre-shared key authentication
chreosistunnel:   child:  10.152.0.0/16 === 196.35.194.232/32 196.35.194.161/32 196.35.194.171/32 196.35.194.188/32 196.35.194.183/32 TUNNEL, dpdaction=clear
chreosistunnel[251]: ESTABLISHED 79 seconds ago, 172.30.0.143[54.228.251.166]...196.34.134.31[196.34.134.31]
chreosistunnel[251]: IKEv1 SPIs: 5ecfd8e0a7504b26_i 4cfda362104367de_r*, pre-shared key reauthentication in 7 hours
chreosistunnel[251]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
chreosistunnel[251]: Tasks passive: QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE

As can be seen from the logs, the 5 CHILD_SA's stay in passive tasks, waiting for the HASH.

This worked in Linux strongSwan U5.1.2/K3.13.0-32-generic

clientfirewallconfig.log (702 Bytes) clientfirewallconfig.log proprietary client config Pieter Jordaan, 19.09.2015 16:11
strongswanlogfailure.log (2.21 KB) strongswanlogfailure.log excerpt of a HASH failure Pieter Jordaan, 19.09.2015 16:11
swipsec.conf (1.02 KB) swipsec.conf ipsec.conf Pieter Jordaan, 19.09.2015 16:11
strongswanlog.log (581 KB) strongswanlog.log completer log without ENC logging Pieter Jordaan, 19.09.2015 16:11

Related issues

Copied to Feature #1128: Make number of tracked Quick Mode states configurableClosed2015-09-19

History

#1 Updated by Pieter Jordaan over 3 years ago

Please only consider chreosistunnel related log entries. The rest is transport mode connections and unrelated.

#2 Updated by Tobias Brunner over 3 years ago

  • Status changed from New to Feedback
  • Priority changed from Urgent to Normal

The IKE daemon charon only tracks two concurrent Quick Mode exchanges by default. Since the last QM messages of all five exchanges arrive after all initial messages have been handled, the state of the first three has already been replaced, however, these messages again will replace the states so even the last two exchanges can't be completed successfully. You can increase the number of states to track at source:src/libcharon/sa/ikev1/keymat_v1.c#L30.

#3 Updated by Pieter Jordaan over 3 years ago

Tobias Brunner wrote:

The IKE daemon charon only tracks two concurrent Quick Mode exchanges by default. Since the last QM messages of all five exchanges arrive after all initial messages have been handled, the state of the first three has already been replaced, however, these messages again will replace the states so even the last two exchanges can't be completed successfully. You can increase the number of states to track at source:src/libcharon/sa/ikev1/keymat_v1.c#L30.

Hi Tobias, thanks.

That makes a lot of sense. Will it be possible to expose these variable to the config? Should I open a new ticket for that?

I'm quickly building and testing with the changed parameters. If this solves my issue, I will close it.

#4 Updated by Pieter Jordaan over 3 years ago

I've tested and all are now established:

chreosistunnel:  172.30.0.143...196.34.134.31  IKEv1/2, dpddelay=120s
chreosistunnel:   local:  [54.228.251.166] uses pre-shared key authentication
chreosistunnel:   remote: [196.34.134.31] uses pre-shared key authentication
chreosistunnel:   child:  10.152.0.0/16 === 196.35.194.232/32 196.35.194.161/32 196.35.194.171/32 196.35.194.188/32 196.35.194.183/32 TUNNEL, dpdaction=clear
chreosistunnel{132}:  ROUTED, TUNNEL, reqid 130
chreosistunnel{132}:   10.152.0.0/16 === 196.35.194.161/32 196.35.194.171/32 196.35.194.183/32 196.35.194.188/32 196.35.194.232/32 
chreosistunnel[15]: ESTABLISHED 111 seconds ago, 172.30.0.143[54.228.251.166]...196.34.134.31[196.34.134.31]
chreosistunnel[15]: IKEv1 SPIs: 93c7b2f5c89f6435_i 8815e1008f5bd2fd_r*, pre-shared key reauthentication in 7 hours
chreosistunnel[15]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
chreosistunnel{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: ce736eeb_i 7b1de0d8_o
chreosistunnel{1}:  3DES_CBC/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
chreosistunnel{1}:   10.152.0.0/16 === 196.35.194.171/32 
chreosistunnel{2}:  INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: c31f6a4d_i 7b1de0d9_o
chreosistunnel{2}:  3DES_CBC/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
chreosistunnel{2}:   10.152.0.0/16 === 196.35.194.183/32 
chreosistunnel{3}:  INSTALLED, TUNNEL, reqid 3, ESP in UDP SPIs: c750ec19_i 7b1de0da_o
chreosistunnel{3}:  3DES_CBC/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
chreosistunnel{3}:   10.152.0.0/16 === 196.35.194.232/32 
chreosistunnel{4}:  INSTALLED, TUNNEL, reqid 4, ESP in UDP SPIs: c17372e5_i 7b1de0db_o
chreosistunnel{4}:  3DES_CBC/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
chreosistunnel{4}:   10.152.0.0/16 === 196.35.194.161/32 
chreosistunnel{5}:  INSTALLED, TUNNEL, reqid 5, ESP in UDP SPIs: cc4559f9_i 7b1de0dc_o
chreosistunnel{5}:  3DES_CBC/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
chreosistunnel{5}:   10.152.0.0/16 === 196.35.194.188/32 

I've called

sudo ipsec route chreosistunnel
sudo ip route list table 220

The table shows:

196.35.194.161 via 172.30.0.1 dev eth0  proto static  src 10.152.1.1 
196.35.194.171 via 172.30.0.1 dev eth0  proto static  src 10.152.1.1 
196.35.194.183 via 172.30.0.1 dev eth0  proto static  src 10.152.1.1 
196.35.194.188 via 172.30.0.1 dev eth0  proto static  src 10.152.1.1 
196.35.194.232 via 172.30.0.1 dev eth0  proto static  src 10.152.1.1 

However,

sudo traceroute -s 10.152.1.1 196.35.194.161 #or any of the connected CHILD_SA's#

Doesn't get routed through the tunnel.

#5 Updated by Tobias Brunner over 3 years ago

  • Copied to Feature #1128: Make number of tracked Quick Mode states configurable added

#6 Updated by Tobias Brunner over 3 years ago

Will it be possible to expose these variable to the config?

Please have a look at the 1128-qm-max branch and #1128. Before 5.3.3 this client behavior would actually have resulted in other failures (see #1076).

Doesn't get routed through the tunnel.

Is this traffic just blocked? Or sent unencrypted? You might have to set lefthostaccess=yes if you use leftfirwall=yes with a DROP policy for the INPUT/OUTPUT chain.

#7 Updated by Pieter Jordaan over 3 years ago

Tobias Brunner wrote:

this traffic just blocked? Or sent unencrypted? You might have to set lefthostaccess=yes if you use leftfirwall=yes with a DROP policy for the INPUT/OUTPUT chain.

The traffic is sent unencrypted through eth0, and doesn't get affected by the installed policy or ip routing table.
I have masquerading enabled for the transport connections

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  10.152.0.0/16        0.0.0.0/0            policy match dir out pol ipsec
MASQUERADE  all  --  10.152.0.0/16        0.0.0.0/0 

These connections "chreosis connection" should use the VPN 10.152.1.1 as gateway except for traffic destined for the tunnel CHILD_SA's which should route through the tunnel. Again this used to work with 5.1.2.

#8 Updated by Tobias Brunner over 3 years ago

Probably due to mark=%unique. As you will see in the output of ip xfrm policy the policies will have a mark assigned, which means packets only match them if they also are marked accordingly. Unless you actually use this mark for something (e.g. mark traffic via iptables) just remove it.

#9 Updated by Pieter Jordaan over 3 years ago

Tobias Brunner wrote:

Probably due to mark=%unique. As you will see in the output of ip xfrm policy the policies will have a mark assigned, which means packets only match them if they also are marked accordingly. Unless you actually use this mark for something (e.g. mark traffic via iptables) just remove it.

The client tunnel connection also serves as a NAT for devices using it as a gateway for a private APN. If unique isn't needed to support multiple clients from the same NAT, then it should be fine.

#10 Updated by Pieter Jordaan over 3 years ago

Pieter Jordaan wrote:

Tobias Brunner wrote:

Probably due to mark=%unique. As you will see in the output of ip xfrm policy the policies will have a mark assigned, which means packets only match them if they also are marked accordingly. Unless you actually use this mark for something (e.g. mark traffic via iptables) just remove it.

The client tunnel connection also serves as a NAT for devices using it as a gateway for a private APN. If unique isn't needed to support multiple clients from the same NAT, then it should be fine.

I can confirm it does in fact work. This did NOT work in 5.1.2, but the fix in 5.3.0 regarding the NAT issue resolved this. Not the mark=%unique. I can confirm everything works as expected now.

Thanks for your support and awesome software

#11 Updated by Tobias Brunner over 3 years ago

  • Category changed from charon to interoperability
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to Fixed

OK, great you got it working.

Also available in: Atom PDF