Project

General

Profile

Feature #2314

Connecting to WatchGuard with IKEv1 Aggressive Mode requires that the HASH payload is the first one in the third AM request

Added by Jiri Zendulka about 2 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Category:
ikev1
Target version:
Start date:
Due date:
Estimated time:
Resolution:
Fixed

Description

I am not able to get work ikev1 connection between strongswan and watchguard (firebox) in aggressive mode. Phase 1 is successfull on strongswan side but on watchguard side not. It reports:


 Phase 1 started by peer with policy [gateway.4] from 89.xx.xx.xx:500 aggressive mode, pri=6, proc_id=iked, msg_id=",9618820,

 IkeCreateIsakmpSA: init vpnDpdSequenceNum : 262831126(Isakmp SA 0x101cc568), pri=6, proc_id=iked, msg_id=",9618819,

 After id match, use IKE Policy [gateway.4, dev:eth0] for peer IP:89.xx.xx.xx, numXform:1, pkt ifIndex:2, pri=6, proc_id=iked, msg_id=",9618818,

 ******** RECV an IKE packet at 84.xx.xx.x:500(socket:11 ifIndex:2) from Peer 89.xx.xx.xx:500 ********, pri=6, proc_id=iked, msg_id=",9618781,

 ike_process_pkt : ProcessData returned error (-1) , pri=6, proc_id=iked, msg_id=",9618915,

 Discard received phase 2 message from 89.xx.xx.xx:500 to 84.xx.xx.xx:500 cookies i:4d5dd9ec 2c41716f r:f2c312cc f58c1678 before phase 1 is complete, pri=4, proc_id=iked, msg_id=",9618914,

 ******** RECV an IKE packet at 84.xx.xx.xx:500(socket:11 ifIndex:2) from Peer 89.xx.xx.xx:500 ********, pri=6, proc_id=iked, msg_id=" 

 ike_process_pkt : ProcessData returned error (-1) , pri=6, proc_id=iked, msg_id=" 

 IKE phase-1 negotiation from 84.xx.xx.xx:500 to 89.xx.xx.xx:500 failed. Gateway-Endpoint:'gateway.4' Reason:Received invalid aggressive mode hash payload. Check VPN IKE diagnostic log messages  for more information., pri=3, proc_id=iked, msg_id=",9618885,

 Process 3rd Msg (AM): failed to process hash payload, pri=3, proc_id=iked, msg_id=" 

 IkeAMProcessHashMsg : IkeCheckPayloads failed , pri=3, proc_id=iked, msg_id=" 

 Check Payloads : next should be HASH payload, pri=3, proc_id=iked, msg_id=" 

 Received aggressive mode 3rd message with policy 'gateway.4' from 89.xx.xx.xx:500, pri=6, proc_id=iked, msg_id=",9618881

Strongswan's ipsec.conf:

conn ipsec1
 left=89.xx.xx.xx
 right=84.xx.xx.xx
 leftid=@@conel
 rightid=84.xx.xx.xx
 leftauth=psk
 rightauth=psk
 leftsubnet=10.70.0.144/29
 rightsubnet=10.0.5.0/24
 leftupdown=/etc/scripts/updown
 keyexchange=ikev1
 ikelifetime=3600
 keylife=3600
 rekeymargin=30
 rekeyfuzz=100%
 keyingtries=%forever
 type=tunnel
 aggressive=yes
 ike=aes256-sha1-modp3072!
 esp=aes128-sha1!
 auto=start

IPsec status:
Status of IKE charon daemon (weakSwan 5.4.0, Linux 3.5.0-lsp-3.3.1, armv5tejl):
  uptime: 4 minutes, since May 03 14:44:49 2017
  malloc: sbrk 405504, mmap 0, used 123720, free 281784
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 6
  loaded plugins: charon nonce pem openssl kernel-netlink socket-default stroke updown xauth-generic unity
Listening IP addresses:
  10.70.0.145
  xx.xx.xx.xx
Connections:
      ipsec1:  89.xx.xx.xx...84.xx.xx.xx  IKEv1 Aggressive
      ipsec1:   local:  [conel] uses pre-shared key authentication
      ipsec1:   remote: [84.xx.xx.xx] uses pre-shared key authentication
      ipsec1:   child:  10.70.0.144/29 === 10.0.5.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
      ipsec1[2]: ESTABLISHED 104 seconds ago, 89.xx.xx.xx[conel]...84.xx.xx.xx[84.xx.xx.xx]
      ipsec1[2]: IKEv1 SPIs: 7347d25ed81aef63_i* 5a3a452d5cadddb5_r, pre-shared key reauthentication in 57 minutes
      ipsec1[2]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_3072
      ipsec1[2]: Tasks queued: ISAKMP_DELETE QUICK_MODE 
      ipsec1[2]: Tasks active: QUICK_MODE 

Strongswan's log:
2017-05-03 15:09:53 charon: 14[IKE] IKE_SA ipsec1[10] established between 89.xx.xx.xx[conel]...84.xx.xx.xx[84.xx.xx.xx] 
2017-05-03 15:09:53 charon: 14[IKE] scheduling reauthentication in 3555s 
2017-05-03 15:09:53 charon: 14[IKE] maximum IKE_SA lifetime 3585s 
2017-05-03 15:09:53 charon: 14[ENC] generating AGGRESSIVE request 0 [ NAT-D NAT-D HASH ] 
2017-05-03 15:09:53 charon: 14[NET] sending packet: from 89.xx.xx.xx[500] to 84.xx.xx.xx[500] (108 bytes) 
2017-05-03 15:09:53 charon: 14[ENC] generating QUICK_MODE request 2344175958 [ HASH SA No ID ID ] 
2017-05-03 15:09:53 charon: 14[NET] sending packet: from 89.xx.xx.xx[500] to 84.xx.xx.xx[500] (188 bytes) 
2017-05-03 15:09:55 charon: 09[NET] received packet: from 84.xx.xx.xx[500] to 89.xx.xx.x[500] (608 bytes) 
2017-05-03 15:09:55 charon: 09[IKE] received retransmit of response with ID 0, resending last request 
...

Do you have any idea why it does not work?

Associated revisions

Revision 08b19dd0 (diff)
Added by Tobias Brunner about 2 years ago

ikev1: Send NAT-D payloads after HASH payloads in Aggressive Mode requests

Some implementations seem to have problems if the third AM message
contains NAT-D payloads before the HASH payload.

Fixes #2314.

History

#1 Updated by Tobias Brunner about 2 years ago

  • Description updated (diff)
  • Status changed from New to Feedback
  • Priority changed from High to Normal

Most likely an incorrect PSK.

#2 Updated by Jiri Zendulka about 2 years ago

I do not think so. If I intentionally change PSK to wrong one ike is not established at all. Strongswan reports:

[IKE] calculated HASH does not match HASH payload

I tried the newest version of strongswan (5.5.2). Result is the same.

#3 Updated by Tobias Brunner about 2 years ago

OK. Perhaps the other implementation has a problem if it receives the Quick Mode request before it received the third Aggressive Mode message. Do you have to use Aggressive Mode? If so, I guess you could try to delay the Quick Mode message using charon.send_delay and charon.send_delay_type (set the latter to 32).

Check VPN IKE diagnostic log messages for more information

Did you do that? Or is that the output you already posted above?

#4 Updated by Jiri Zendulka about 2 years ago

I set 500/1000/3000 ms for delay in charon.conf

# Delay in ms for sending packets, to simulate larger RTT.
  send_delay = 500

# Specific IKEv2 message type to delay, 0 for any.
  send_delay_type = 32

strongswan's log:

[NET] using send delay: 500ms

But it does not help.

Aggressive mode is needed.
Note: with Mikrotik it works.

In IKE diagnostic log is mentioned "Wait HASH". I think that the reason is

Reason:Received invalid aggressive mode hash payload

But I do not know what this really does mean.
In this situation the strongswan is initator (device with dynamic IP) and watchguard is responder (static IP).

But if the strongswan is responder and the watchguard is initiator then IPsec tunnel is successfully installed. So I guess that PSK, IDs are set correctly. But changing role initiator/responder is not usable for us. We did it only for test.

#5 Updated by Jiri Zendulka about 2 years ago

Diagnostic log from WatchGuard:

[Gateway Summary]
                             Gateway "gateway.4" contains "1" gateway endpoint(s). 
                               Gateway Endpoint #1 (name "gateway.4") Enabled
                                                          Mode: Aggressive                      PFS: Disabled AlwaysUP: Disabled
                                                          DPD: Enabled Keepalive: Disabled
                                                          Local ID<->Remote ID: {IP_ADDR(84.xx.xx.xx) <-> USER_ID_DOMAIN(conel)}
                                                          Local GW_IP<->Remote GW_IP: {84.xx.xx.xx <-> 89.xx.xx.xx}
                                                          Outgoing Interface: eth0 (ifIndex=2)
                                                                                       ifMark=0x10000
                                                                                       linkStatus=0 (0:unknown, 1:down, 2:up)
                                                          Stored user messages:
                                                                  May 04 09:53:43 2017 ERROR  0x02030015 Message retry timeout. Check the connection between local and remote gateway endpoints.

[Tunnel Summary]
                             "1" tunnel(s) are found using the previous gateway

                               Name: "tunnel.6" Enabled
                                                          PFS: "Disabled" DH-Group: "2" 
                                                          Number of Proposals: "1" 
                                                            Proposal "phase2_proposal.2" 
                                                                                       ESP:
                                                                                         EncryptAlgo: "AES" KeyLen: "16(bytes)" 
                                                                                         AuthAlgo: "SHA" 
                                                                                         LifeTime: "120(seconds)" LifeByte: "0(kbytes)" 
                                                          Number of Tunnel Routes: "1" 
                                                                                       #1
                                                                                         Direction: "BOTH" 
                                                                                         "10.0.5.0/24<->10.70.0.144/29" 

[Run-time Info (gateway IKE_SA)]
                             Name: "gateway.4" (IfStatus: 0x80000001)
                               ISAKMP SAID: "0x0" State: "Hash Wait" 
                               Created: Thu Jan  1 01:00:00 1970
                               My Address: 84.xx.xx.xx:500                         Peer Address: 89.xx.xx.xx:500
                               InitCookie: "990f6820b089543c"                     RespCookie: "9f9e29c6c4307708" 
                               LifeTime: "120(seconds)" LifeByte: "0(kbtyes)" DPD: "Enabled" 

[Run-time Info (tunnel IPSEC_SA)]
                             "0" IPSEC SA(s) are found under tunnel "tunnel.6" 

[Run-time Info (tunnel IPSEC_SP)]
                             "0" IPSEC SP(s) are found under tunnel "tunnel.6" 

[Address Pairs in Firewalld]
                             Address Pairs for tunnel "tunnel.6" 
                                                          Direction: BOTH
                                                          10.0.5.0/24 <-> 10.70.0.144/29

[Policy checker result]
                             Tunnel name: tunnel.6
                                                          #1 tunnel route 10.0.5.0/24<->10.70.0.144/29
                                                          No policy checker results for this tunnel(no P2SA found or some other error)

[Related Logs]
<158>May  4 09:53:31 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)Received aggressive mode 3rd message with policy 'gateway.4' from 89.xx.xx.xx:500
<155>May  4 09:53:31 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)Check Payloads : next should be HASH payload
<155>May  4 09:53:31 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)IkeAMProcessHashMsg : IkeCheckPayloads failed 
<155>May  4 09:53:31 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)Process 3rd Msg (AM): failed to process hash payload
<155>May  4 09:53:31 iked[2344]: msg_id="0203-000D" (84.xx.xx.xx<->89.xx.xx.xx)IKE phase-1 negotiation from 84.xx.xx.xx:500 to 89.xx.xx.xx:500 failed. Gateway-Endpoint='gateway.4' Reason=Received invalid aggressive mode hash payload. Check VPN IKE diagnostic log messages for more information.
<158>May  4 09:53:31 iked[2344]: (84.2xx.xx.xx<->89.xx.xx.xx)ike_process_pkt : ProcessData returned error (-1) 
<158>May  4 09:53:35 iked[2344]: (84.2xx.xx.xx<->89.xx.xx.xx)Received aggressive mode 3rd message with policy 'gateway.4' from 89.xx.xx.xx:500
<155>May  4 09:53:35 iked[2344]: (84.2xx.xx.xx<->89.xx.xx.xx)Check Payloads : next should be HASH payload
<155>May  4 09:53:35 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)IkeAMProcessHashMsg : IkeCheckPayloads failed 
<155>May  4 09:53:35 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)Process 3rd Msg (AM): failed to process hash payload
<155>May  4 09:53:35 iked[2344]: msg_id="0203-000D" (84.xx.xx.xx<->89.xx.xx.xx)IKE phase-1 negotiation from 84.xx.xx.xx:500 to 89xx.xx.xx:500 failed. Gateway-Endpoint='gateway.4' Reason=Received invalid aggressive mode hash payload. Check VPN IKE diagnostic log messages for more information.
<158>May  4 09:53:35 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)ike_process_pkt : ProcessData returned error (-1) 
<155>May  4 09:53:38 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)Process INFO_EXCHANGE : EncryptBit set before SA created
<158>May  4 09:53:38 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)ike_process_pkt : ProcessData returned error (-1) 
<158>May  4 09:53:39 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)Resending phase-1 message to 89.xx.xx.xx:500. Gateway:gateway.4 p1saId:0x0
<158>May  4 09:53:43 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)IkeCreateIsakmpSA: init vpnDpdSequenceNum = 65262912(Isakmp SA 0x101dbcf8)
<158>May  4 09:53:43 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)Phase 1 started by peer with policy [gateway.4] from 89.xx.xx.xx:500 aggressive mode
<158>May  4 09:53:43 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)IkeCheckPayloads : Payload(SA) Len(56)
<158>May  4 09:53:43 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)IkeCheckPayloadsG: Payload(4) Len(388)
<158>May  4 09:53:43 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)IkeCheckPayloadsG: Payload(10) Len(36)
<158>May  4 09:53:43 iked[2344]: (84.2xx.xx.xx<->89.xx.xx.xx)IkeCheckPayloadsG: Payload(5) Len(13)
<158>May  4 09:53:43 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)IkeCheckPayloadsG: Payload(13) Len(20)
<158>May  4 09:53:43 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)IkeCheckPayloadsG: Payload(13) Len(20)
<158>May  4 09:53:43 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)IkeCheckPayloadsG: Payload(13) Len(20)
<158>May  4 09:53:43 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)IkeCheckPayloadsG: Payload(13) Len(20)
<158>May  4 09:53:43 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)IkeProposalNtoH : Recv SPI(0000 0000 0000 0x24) SPI(0000 0000 0000 0000)  
<158>May  4 09:53:43 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)IkeProposalHtoN : net order spi(0000 0000 0000 0000)  
<158>May  4 09:53:43 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)Received VID_PAYLOAD - VPN_DPD_VID(first 4bytes: 0xafcad713) 
<158>May  4 09:53:43 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)Enable DPD locally
<158>May  4 09:53:43 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)Received VID_PAYLOAD - VPN_NAT-T_VID(first 4bytes: 0x9180cb90)
<158>May  4 09:53:43 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)P1__Mode: NAT-T negotiated [gateway.4] peer 0x5918013e:500
<158>May  4 09:53:43 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)Sending aggressive mode 2nd message with policy 'gateway.4' to 89.xx.xx.xx:500
<155>May  4 09:53:43 iked[2344]: msg_id="0203-0015" (84.xx.xx.xx<->89.xx.xx.xx)IKE phase-1 negotiation from 84.xx.xx.xx0:500 to 89.xx.xx.xx:500 failed. Gateway-Endpoint='gateway.4' Reason=Message retry timeout. Check the connection between local and remote gateway endpoints.
<158>May  4 09:53:43 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)ike_p1_status_chg: ikePcyName=gateway.4, status=DOWN

#6 Updated by Tobias Brunner about 2 years ago

I guess this could be the problem:

<155>May  4 09:53:31 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)Check Payloads : next should be HASH payload
<155>May  4 09:53:31 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)IkeAMProcessHashMsg : IkeCheckPayloads failed 
<155>May  4 09:53:31 iked[2344]: (84.xx.xx.xx<->89.xx.xx.xx)Process 3rd Msg (AM): failed to process hash payload
2017-05-03 15:09:53 charon: 14[ENC] generating AGGRESSIVE request 0 [ NAT-D NAT-D HASH ] 

As you can see strongSwan sends the NAT-D payloads before the HASH payload. In RFC 3947 the example exchanges use public key authentication where the SIG payload is placed at the end. And RFC 2409 has no explicit restrictions on the order. Well, in the AM example it's the only payload, but in the Main Mode example the ID payloads are before the HASH payloads. However, for Quick Mode exchanges the RFC explicitly demands that the HASH payloads are the first payload in the message. Perhaps this WatchGuard box can only handle the third AM message if that's the case too (it's strange that it can handle the second message by strongSwan as initiator because there the HASH payload is also not the first one).

You can try changing the order of the payloads with the patch in the 2314-am-nat-d-order branch.

#7 Updated by Jiri Zendulka about 2 years ago

It works! Many thanks for that.

Questions:

Could this patch somehow break interoperability with other platfroms (i.e. cisco, std. strongswan)?

Do you plan merge this branch to master (= it appears this patch in future release)?

Thanks.

#8 Updated by Tobias Brunner about 2 years ago

  • Tracker changed from Issue to Feature
  • Category set to ikev1
  • Target version set to 5.5.3

Could this patch somehow break interoperability with other platfroms (i.e. cisco, std. strongswan)?

Could be, who knows what other implementations do. strongSwan, though, does not care in which order payloads arrive.

Do you plan merge this branch to master (= it appears this patch in future release)?

Sure.

#9 Updated by Tobias Brunner about 2 years ago

  • Subject changed from Strongswan and WatchGuard (IKEv1 aggressive mode) does not work to Connecting to WatchGuard with IKEv1 Aggressive Mode requires that the HASH payload is the first one in the third AM request
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to Fixed

Also available in: Atom PDF