Hi Martin,
thanks for the fast response. We have tested the patch and it brings us one
step further. The IKE Rekeying succeeds, but afterwards it gets stuck within a
mode_config request. I don't think there should be a mode_config request during
rekeying or I am wrong? After this first rekeying no further traffic is going
thru the tunnel.
Here is the log of the first IKE rekeying:
Mar 11 15:50:48 ThinClient charon: 14[IKE] XAuth authentication of 'ecos'
(myself) successful
Mar 11 15:50:48 ThinClient charon: 14[IKE] deleting duplicate IKE_SA for peer
'1.2.3.4' due to uniqueness policy
Mar 11 15:50:48 ThinClient charon: 14[IKE] queueing ISAKMP_DELETE task
Mar 11 15:50:48 ThinClient charon: 14[IKE] activating new tasks
Mar 11 15:50:48 ThinClient charon: 14[IKE] activating ISAKMP_DELETE task
Mar 11 15:50:48 ThinClient charon: 14[IKE] deleting IKE_SA vvph_aggr_mode[1]
between 192.168.192.117[admin]...1.2.3.4[1.2.3.4]
Mar 11 15:50:48 ThinClient charon: 14[IKE] sending DELETE for IKE_SA
vvph_aggr_mode[1]
Mar 11 15:50:48 ThinClient charon: 14[IKE] IKE_SA vvph_aggr_mode[1] state
change: ESTABLISHED => DELETING
Mar 11 15:50:48 ThinClient charon: 14[CFG] nm ike_state_change, ike_sa =
vvph_aggr_mode[1] my sa = yes, state = DELETING
Mar 11 15:50:48 ThinClient charon: 14[CFG] nm ike_updown, ike_sa =
vvph_aggr_mode[1] my sa = yes, down
Mar 11 15:50:48 ThinClient charon: 14[IKE] Hash => 20 bytes @ 0x4081f300
Mar 11 15:50:48 ThinClient charon: 14[IKE] 0: 55 1C BF E6 6C A8 4E DD 26 CD
D8 5C F7 56 5E 11 U...l.N.&..\.V^.
Mar 11 15:50:48 ThinClient charon: 14[IKE] 16: 70 62 B5 62
pb.b
Mar 11 15:50:48 ThinClient charon: 14[ENC] generating INFORMATIONAL_V1 request
2158569415 [ HASH D ]
Mar 11 15:50:48 ThinClient charon: 14[IKE] next IV for MID 2158569415 => 8
bytes @ 0x408196d8
Mar 11 15:50:48 ThinClient charon: 14[IKE] 0: F9 DD 5D F7 26 45 CE 66
..].&E.f
Mar 11 15:50:48 ThinClient charon: 14[IKE] next IV for MID 2158569415 => 8
bytes @ 0x4080c000
Mar 11 15:50:48 ThinClient charon: 14[IKE] 0: 25 41 1B D8 B2 10 F7 2E
%A......
Mar 11 15:50:48 ThinClient charon: 14[NET] sending packet: from
192.168.192.117[4500] to 1.2.3.4[4500] (84 bytes)
Mar 11 15:50:48 ThinClient charon: 14[IKE] IKE_SA vvph_aggr_mode[1] state
change: DELETING => DESTROYING
Mar 11 15:50:48 ThinClient charon: 14[CFG] nm ike_state_change, ike_sa =
vvph_aggr_mode[1] my sa = yes, state = DESTROYING
Mar 11 15:50:48 ThinClient charon: 14[IKE] IKE_SA vvph_aggr_mode[2] established
between 192.168.192.117[admin]...1.2.3.4[1.2.3.4]
Mar 11 15:50:48 ThinClient charon: 14[IKE] IKE_SA vvph_aggr_mode[2] state
change: CONNECTING => ESTABLISHED
Mar 11 15:50:48 ThinClient charon: 14[IKE] scheduling reauthentication in 3558s
Mar 11 15:50:48 ThinClient charon: 14[IKE] maximum IKE_SA lifetime 3588s
Mar 11 15:50:48 ThinClient charon: 14[IKE] Hash => 20 bytes @ 0x4080fe10
Mar 11 15:50:48 ThinClient charon: 14[IKE] 0: 6E 21 CA AC DD 1F 65 18 9D 5D
43 18 67 07 FD 29 n!....e..]C.g..)
Mar 11 15:50:48 ThinClient charon: 14[IKE] 16: 8A 41 11 4F
.A.O
Mar 11 15:50:48 ThinClient charon: 14[ENC] generating TRANSACTION response
1481556635 [ HASH CP ]
Mar 11 15:50:48 ThinClient charon: 14[IKE] next IV for MID 1481556635 => 8
bytes @ 0x4080fed8
Mar 11 15:50:48 ThinClient charon: 14[IKE] 0: 82 63 04 AD A3 89 D0 66
.c.....f
Mar 11 15:50:48 ThinClient charon: 14[NET] sending packet: from
192.168.192.117[4500] to 1.2.3.4[4500] (68 bytes)
Mar 11 15:50:48 ThinClient charon: 14[IKE] activating new tasks
Mar 11 15:50:48 ThinClient charon: 14[IKE] activating MODE_CONFIG task
Mar 11 15:50:48 ThinClient charon: 14[IKE] building INTERNAL_IP4_DNS attribute
Mar 11 15:50:48 ThinClient charon: 14[IKE] building INTERNAL_IP4_DNS attribute
Mar 11 15:50:48 ThinClient charon: 14[IKE] building INTERNAL_IP4_NBNS attribute
Mar 11 15:50:48 ThinClient charon: 14[IKE] building UNITY_SPLIT_INCLUDE
attribute
Mar 11 15:50:48 ThinClient charon: 14[IKE] building UNITY_LOCAL_LAN attribute
Mar 11 15:50:48 ThinClient charon: 14[IKE] Hash => 20 bytes @ 0x4081e018
Mar 11 15:50:48 ThinClient charon: 14[IKE] 0: 11 8D EA D6 ED AC F9 52 E3 47
F6 5C 0A E5 6D 73 .......R.G.\..ms
Mar 11 15:50:48 ThinClient charon: 14[IKE] 16: 25 B3 1F DC
%...
Mar 11 15:50:48 ThinClient charon: 14[ENC] generating TRANSACTION request
3572047518 [ HASH CP ]
Mar 11 15:50:48 ThinClient charon: 14[IKE] next IV for MID 3572047518 => 8
bytes @ 0x4081e018
Mar 11 15:50:48 ThinClient charon: 14[IKE] 0: 28 80 A3 40 EE 83 9B BF
(..@....
Mar 11 15:50:48 ThinClient charon: 14[IKE] next IV for MID 3572047518 => 8
bytes @ 0x4081d908
Mar 11 15:50:48 ThinClient charon: 14[IKE] 0: BC 37 61 74 C4 DD BF E3
.7at....
Mar 11 15:50:48 ThinClient charon: 14[NET] sending packet: from
192.168.192.117[4500] to 1.2.3.4[4500] (92 bytes)
Mar 11 15:50:52 ThinClient charon: 01[IKE] sending retransmit 1 of request
message ID 3572047518, seq 1
Mar 11 15:50:52 ThinClient charon: 01[NET] sending packet: from
192.168.192.117[4500] to 1.2.3.4[4500] (92 bytes)
Mar 11 15:50:59 ThinClient charon: 12[IKE] sending retransmit 2 of request
message ID 3572047518, seq 1
Mar 11 15:50:59 ThinClient charon: 12[NET] sending packet: from
192.168.192.117[4500] to 1.2.3.4[4500] (92 bytes)
Mar 11 15:51:12 ThinClient charon: 13[IKE] sending retransmit 3 of request
message ID 3572047518, seq 1
Mar 11 15:51:12 ThinClient charon: 13[NET] sending packet: from
192.168.192.117[4500] to 1.2.3.4[4500] (92 bytes)
Mar 11 15:51:35 ThinClient charon: 14[IKE] sending retransmit 4 of request
message ID 3572047518, seq 1
Mar 11 15:51:35 ThinClient charon: 14[NET] sending packet: from
192.168.192.117[4500] to 1.2.3.4[4500] (92 bytes)
Mar 11 15:52:17 ThinClient charon: 02[IKE] sending retransmit 5 of request
message ID 3572047518, seq 1
Mar 11 15:52:17 ThinClient charon: 02[NET] sending packet: from
192.168.192.117[4500] to 1.2.3.4[4500] (92 bytes)
Mar 11 15:53:33 ThinClient charon: 12[IKE] giving up after 5 retransmits
Regards
Gerald
> -----Ursprüngliche Nachricht-----
> Von: Martin Willi [mailto:[email protected]]
> Gesendet: Freitag, 8. März 2013 15:25
> An: Gerald Richter - ECOS
> Cc: [email protected]
> Betreff: Re: [strongSwan] Aggressive Mode. Rekeying fails
>
> Hi Gerald,
>
> > 14[IKE] key derivation for XAuthRespPSK failed
>
> While we have some basic support to authenticate the responder with
> XAuth, it seems that the XAuthRespPSK case got lost somehow in key
> derivation.
>
> I haven't tried it at all, but the attached patch might fix the issue.
>
> Regards
> Martin
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
