[strongSwan] connection to watchguard: failed to process hash payload

[Gerald Richter - ECOS]

Hi,

 
while trying to connect to a watchguard, the watchguard log shows the following message:

 
Process 3rd Msg (AM): failed to process hash payload

 
It’s an aggressive mode connection and the first message is sent successfully and a reply is received. When strongswan sends it’s second message to the watchguard, the watchguard log shows the above message (log see below).

 
I have verified the connection with two other clients (vpnc, which gets stuck during xauth) and shrew soft windows clients (which succeeds with the connection) and everything looks the same. The only difference I can see is that the other clients sends more NAT-T VID payloads.

 
Could it be that the hash is really miscalculated?

 
Any idea how to track down this issue?

 
Thanks & Regards

 
Gerald

 
 
charon: 16[IKE] initiating Aggressive Mode IKE_SA iosn[1] to 1.2.3.4 

charon: 16[ENC] generating AGGRESSIVE request 0 [ SA KE No ID V V V V V ] 

charon: 16[NET] sending packet: from 10.11.12.75[500] to 1.2.3.4[500] (410 bytes) 

charon: 05[NET] received packet: from 1.2.3.4[500] to 10.11.12.75[500] (360 bytes) 

charon: 05[ENC] parsed AGGRESSIVE response 0 [ SA KE No ID V V NAT-D NAT-D V HASH ] 

charon: 05[IKE] received DPD vendor ID 

charon: 05[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID 

charon: 05[IKE] received XAuth vendor ID 

charon: 05[IKE] local host is behind NAT, sending keep alives 

charon: 05[ENC] generating AGGRESSIVE request 0 [ NAT-D NAT-D HASH ] 

charon: 05[NET] sending packet: from 10.11.12.75[4500] to 1.2.3.4[4500] (108 bytes) 

charon: 04[NET] received packet: from 1.2.3.4[4500] to 10.11.12.75[4500] (360 bytes) 

charon: 04[IKE] received retransmit of response with ID 0, resending last request 

charon: 04[NET] sending packet: from 10.11.12.75[4500] to 1.2.3.4[4500] (108 bytes)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130702/3dadd0ea/attachment.html>