Project

General

Profile

Bug #556

Updated by Tobias Brunner almost 7 years ago

When using Windows Agile Clients (Windows 7 and Windows 8.1 tested, 64bit arch) as an initiator and with EAP-PEAP or EAP-TTLS client authentication, the TLS Close notify packet sent by the StrongSwan (in responder mode) causes an immediate Windows Agile Client disconnect after a successful authentication if EAP-PEAP is used, or a connection timeout if EAP-TTLS is used. The TLS close notify packet is not understood by the Agile Client. To restore compatibility, commit commit:7bbf7aa97a0acf3d728f 7bbf7aa97a0acf3d728fe4f1e1518e1854050f90 ( http://wiki.strongswan.org/projects/strongswan/repository/revisions/7bbf7aa97a0acf3d728fe4f1e1518e1854050f90 ) should be reverted. Attached are two Charon's logs:

StrongSwan-5.1.2-vanilla.log - showcases the behavior of the vannila Strongswan 5.1.2
StrongSwan-5.1.2-reverted-commit.log - showcases the behavior of the vannila Strongswan 5.1.2 with revert of the problematic patch

The most notable difference is that the vanilla StrongSwan 5.1.2 tries to send TLS close notify and in that way continues the EAP conversation, while the StrongSwan 5.1.2 compiled after the the reversal of the commit sends (in this case - authentication is successful) EAP/SUCC:

_*Vanilla:*_

Mar 28 22:54:01 dev-1 charon: 02[IKE] received tunneled EAP-TTLS AVP [EAP/RES/MSCHAPV2]
Mar 28 22:54:01 dev-1 charon: 02[IKE] EAP_TTLS phase2 authentication of 'iketest' with EAP_MSCHAPV2 successful
*Mar 28 22:54:01 dev-1 charon: 02[TLS] sending TLS close notify*
*Mar 28 22:54:01 dev-1 charon: 02[ENC] generating IKE_AUTH response 11 [ EAP/REQ/TTLS ]*

Windows Agile client believes the EAP conversation is almost over (expects EAP/SUCC or failure), so this "IKE_AUTH response 11" packet seems strange to it. It stalls ( EAP-TTLS ) or disconnects ( EAP-PEAP ).

_*Reverted commit:*_

Mar 29 15:55:11 dev-1 charon: 09[IKE] received tunneled EAP-TTLS AVP [EAP/RES/MSCHAPV2]
Mar 29 15:55:11 dev-1 charon: 09[IKE] EAP_TTLS phase2 authentication of 'iketest' with EAP_MSCHAPV2 successful
Mar 29 15:55:11 dev-1 charon: 09[IKE] EAP method EAP_TTLS succeeded, MSK established
*Mar 29 15:55:11 dev-1 charon: 09[ENC] generating IKE_AUTH response 8 [ EAP/SUCC ]*

Windows Agile Client expects EAP/SUCC packet or a failure and does recieve, in this case, EAP/SUCC. StrongSwan then goes on setting up routes and with the rest of the connection setup process.

This issue is easy to reproduce and reverting the mentioned commit resolves it. In my opinion this commit creates a big compatibility issue and that's why I think it is urgent to fix it in the next stable release. Also, this issue is present, probably since the commit was done, and that's a year ago.

BTW. thank you for the wonderful software (StrongSwan) and all your efforts you've put into it :)

Back