Bug #1131
Updated by Tobias Brunner almost 10 years ago
The following behaviour was observed with strongSwan for Android 1.5.0 5.3.3 (from PlayMarket, daemon 5.3.3) PlayMarket) on lossy networks.
Sometimes the VPN connection using IKEv2 with Security Gateway cannot be set with the diagnostic message on SGW - "Invalid signature". Usually the subsequent attempt is successful. The investigations revealed, that when strongSwan performs retransmissions of IKE_SA_INIT messages due to packets loss, it sometimes changes the content of NAT_DETECTION_SOURCE_IP Notification, although the source IP and Port (as well as IKE SPI) remain the same. Depending on which of retransmissions reaches responder, the input to InitiatorSignedOctets (Section 2.15 of RFC7296) is different and the signature validation could fail.
This behaviour was only observed on Android.
Here is the strongSwan log and the corresponding wireshark transcript recorded on SGW (note that SGW address is mangled for privacy reasons).
Description of the transcript:
1. Line 1 - the first IKE_SA_INIT message from strongSwan. NAT_DETECTION_SOURCE_IP contains 423bd2896eb49250ccf8da5e77bfd550948f8ff2 (Line 570)
2. Line 597 - response from SGW, with INVALID_KE_PAYLOAD (seems to get lost)
3. Line 683 - strongSwan resends the first message intact. NAT_DETECTION_SOURCE_IP still contains 423bd2896eb49250ccf8da5e77bfd550948f8ff2 (Line 1250)
4. Line 1276 - again response from SGW, with INVALID_KE_PAYLOAD
5. Line 1362 - strongSwan receives message from SGW and resends its original request wih new KE Payload. But at the same time it changes the content of NAT_DETECTION_SOURCE_IP to 7422b95a724fd9959a00269ebe0635a47682a2f4 (Line 1929), although neither source IP, nor source Port, nor IKE SPIs are changed.
6. Line 1955 - SGW responds to previous message, but his respons seems to get lost
7. Line 2124 - strongSwan retransmits its last message again, and again changing NAT_DETECTION_SOURCE_IP now to 268ee601736293f67fa5582c4a5985759d9d8b78 (Line 2691).
8. Line 2717 - SGW retransmits its response
9. Line 2886, 2964 - strongSwan receives response from SGW and initiates IKE_AUTH exchange sending 2 fragments
10. Line 3042 - SGW reports of failed authentication
Sometimes the VPN connection using IKEv2 with Security Gateway cannot be set with the diagnostic message on SGW - "Invalid signature". Usually the subsequent attempt is successful. The investigations revealed, that when strongSwan performs retransmissions of IKE_SA_INIT messages due to packets loss, it sometimes changes the content of NAT_DETECTION_SOURCE_IP Notification, although the source IP and Port (as well as IKE SPI) remain the same. Depending on which of retransmissions reaches responder, the input to InitiatorSignedOctets (Section 2.15 of RFC7296) is different and the signature validation could fail.
This behaviour was only observed on Android.
Here is the strongSwan log and the corresponding wireshark transcript recorded on SGW (note that SGW address is mangled for privacy reasons).
Description of the transcript:
1. Line 1 - the first IKE_SA_INIT message from strongSwan. NAT_DETECTION_SOURCE_IP contains 423bd2896eb49250ccf8da5e77bfd550948f8ff2 (Line 570)
2. Line 597 - response from SGW, with INVALID_KE_PAYLOAD (seems to get lost)
3. Line 683 - strongSwan resends the first message intact. NAT_DETECTION_SOURCE_IP still contains 423bd2896eb49250ccf8da5e77bfd550948f8ff2 (Line 1250)
4. Line 1276 - again response from SGW, with INVALID_KE_PAYLOAD
5. Line 1362 - strongSwan receives message from SGW and resends its original request wih new KE Payload. But at the same time it changes the content of NAT_DETECTION_SOURCE_IP to 7422b95a724fd9959a00269ebe0635a47682a2f4 (Line 1929), although neither source IP, nor source Port, nor IKE SPIs are changed.
6. Line 1955 - SGW responds to previous message, but his respons seems to get lost
7. Line 2124 - strongSwan retransmits its last message again, and again changing NAT_DETECTION_SOURCE_IP now to 268ee601736293f67fa5582c4a5985759d9d8b78 (Line 2691).
8. Line 2717 - SGW retransmits its response
9. Line 2886, 2964 - strongSwan receives response from SGW and initiates IKE_AUTH exchange sending 2 fragments
10. Line 3042 - SGW reports of failed authentication