Hi Tormod,
> Jan 17 08:22:49 ip-10-130-68-12 charon: 15[IKE] received retransmit of
> request with ID 0, retransmitting response
> Jan 17 08:22:49 ip-10-130-68-12 charon: 15[NET] sending packet: from
> 10.1.1.1[4500] to 444.444.444.444[4500] (76 bytes)
> Jan 17 08:22:51 ip-10-130-68-12 charon: 14[NET] received packet: from
> 444.444.444.444[4500] to 10.1.1.1[4500] (76 bytes)
> Jan 17 08:22:51 ip-10-130-68-12 charon: 14[ENC] parsed INFORMATIONAL request
> 0 [ ]
> Jan 17 08:22:51 ip-10-130-68-12 charon: 14[IKE] received retransmit of
> request with ID 0, retransmitting response
> Jan 17 08:22:51 ip-10-130-68-12 charon: 14[NET] sending packet: from
> 10.1.1.1[4500] to 444.444.444.444[4500] (76 bytes)
> Jan 17 08:22:53 ip-10-130-68-12 charon: 16[NET] received packet: from
> 444.444.444.444[4500] to 10.1.1.1[4500] (76 bytes)
> Jan 17 08:22:53 ip-10-130-68-12 charon: 16[ENC] parsed INFORMATIONAL request
> 0 [ ]
Looks like there are connectivity issues from strongSwan to Cisco (you
should look into what causes these).
While the DPDs sent by Cisco are apparently received by strongSwan the
response is not. So Cisco retransmits the DPD request and at 08:22:59
stops and closes the IKE_SA on its end. Later strongSwan tries to rekey
the CHILD_SA:
> Jan 17 08:42:17 ip-10-130-68-12 charon: 02[KNL] creating rekey job for ESP
> CHILD_SA with SPI c1187d8e and reqid {1}
> Jan 17 08:42:17 ip-10-130-68-12 charon: 02[IKE] establishing CHILD_SA
> ciscoios{1}
> Jan 17 08:42:17 ip-10-130-68-12 charon: 02[ENC] generating CREATE_CHILD_SA
> request 34 [ N(REKEY_SA) SA No TSi TSr ]
> Jan 17 08:42:17 ip-10-130-68-12 charon: 02[NET] sending packet: from
> 10.1.1.1[4500] to 444.444.444.444[4500] (316 bytes)
> Jan 17 08:42:21 ip-10-130-68-12 charon: 10[IKE] retransmit 1 of request with
> message ID 34
> Jan 17 08:42:21 ip-10-130-68-12 charon: 10[NET] sending packet: from
> 10.1.1.1[4500] to 444.444.444.444[4500] (316 bytes)
But that fails either because there are still connectivity issues, or
even if not, because the Cisco box has already closed the IKE_SA and
thus ignores the requests for an unknown SA. After five retransmits
strongSwan likewise closes the IKE_SA.
You could let strongSwan reestablish the SA by setting dpdaction=restart
and perhaps keyingtries=%forever, or you could use auto=route instead of
auto=start. With auto=route SAs are triggered by traffic, so when the
SA is closed the next packet sent to a host in 192.168.0.0/16 will
trigger the SA to get reestablished.
Regards,
Tobias
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
