[strongSwan] Sudden issues with Windows 10 clients

Jafar Al-Gharaibeh jafar at atcorp.com
Wed May 9 06:08:40 CEST 2018


Houman,

      No need to configure a prf, it is already assumed when you 
configured a DH group; so you can drop prfsha256. And as Christian 
suggested, if all your clients support strong encryption  drop all weak 
algorithms/proposals from  the server end i.e 3des, sha1, modp1024. I 
can't believe that  Microsoft still in 2018 offer these as the default 
options and expects users to go tinker with obscured registery keys  to 
enable stronger options.

For ESP, I'd connect the Windows client and see what the offered 
proposals in the logs at the server side, just as you did with ike. You 
can then limit the proposals at the server end to the good ones. If I 
remember well, AES256 was an option, but esp didn't allow a DH group so 
you might need to drop that, but I could be wrong.

Cheers,
Jafar


On 5/8/2018 1:55 PM, Houman wrote:
> Thank you both Christian and Jafar for the clear proposals.
>
> So yes, if I wanted to support Windows 10, iOS/OSX and Linux with the 
> stronger set of encryption. Do I set *aes256-sha256-prfsha256-modp2048 
> *into *ike* only?  Or both in *ike* and *esp*?
>
> This part wasn't quite clear to me.
>
> Yeah, I have already set [NegotiateDH2048_AES256] in Windows 10.
>
> Many Thanks,
> Houman
>
>
>
> On 8 May 2018 at 08:40, Christian Salway <christian.salway at naimuri.com 
> <mailto:christian.salway at naimuri.com>> wrote:
>
>     The problem with Windows (10 at least) is that it offers the
>     weakest ciphers first, so you should remove sha1 and 3des.
>
>     The minimum proposals you should have and which are compatible
>     with Windows 10, OSX, IOS and Linux are the following.
>
>     *proposals = aes256-sha256-prfsha256-modp2048-modp1024*
>
>     Although I would recommend adding the Windows 10 registry key
>     [NegotiateDH2048_AES256] to use strong ciphers and then you can
>     remove MODP1024
>
>
>     <http://www.naimuri.com>
>
>>     On 7 May 2018, at 15:50, Jafar Al-Gharaibeh <jafar at atcorp.com
>>     <mailto:jafar at atcorp.com>> wrote:
>>
>>     Houman,
>>
>>       The Windows client proposals do not match your configured
>>     proposals. Your Windows client expect DG group 15 (MODP2048),
>>     where as you have:
>>
>>     aes256-3des-sha1-modp1024
>>
>>     change that to:
>>
>>     aes256-3des-sha1-modp2048
>>
>>     I'd also add sha256 at least before sha1 (deemed insecure). If
>>     you still have other clients expecting modp1024, make it:
>>
>>     aes256-3des-sha256-sha1-modp2048-modp1024
>>
>>     That should get you covered.
>>
>>     Regards,
>>     Jafar
>>
>>
>>     On 5/7/2018 8:17 AM, Houman wrote:
>>>     Hello,
>>>
>>>     Until a week ago a user with Windows 10 had no issue connecting
>>>     to the StrongSwan server. But now out of the blue, he can't
>>>     connect to the StrongSwan server anymore.
>>>
>>>     The log on the server is:
>>>
>>>     May  7 12:31:06 vpn-p1 charon: 08[IKE] received proposals
>>>     inacceptable
>>>     May  7 12:31:06 vpn-p1 charon: 08[ENC] generating IKE_SA_INIT
>>>     response 0 [ N(NO_PROP) ]
>>>     May  7 12:31:06 vpn-p1 charon: 08[NET] sending packet: from
>>>     xxx.x.xx.92[500] to 91.98.xxx.xxx[500] (36 bytes)
>>>     May  7 12:32:09 vpn-p1 systemd[1]: Started Session 35 of user root.
>>>     May  7 12:46:21 vpn-p1 systemd[1]: Starting Cleanup of Temporary
>>>     Directories...
>>>     May  7 12:46:21 vpn-p1 systemd-tmpfiles[7016]:
>>>     [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path
>>>     "/var/log", ignoring.
>>>     May  7 12:46:21 vpn-p1 systemd[1]: Started Cleanup of Temporary
>>>     Directories.
>>>     May  7 13:00:13 vpn-p1 systemd[1]: Starting Certbot...
>>>     May  7 13:00:13 vpn-p1 systemd[1]: Started Certbot.
>>>     May  7 13:08:20 vpn-p1 systemd[1]: Started Session 36 of user root.
>>>     May  7 13:11:27 vpn-p1 charon: 12[NET] received packet: from
>>>     91.98.xxx.xxx[500] to xxx.x.xx.92[500] (624 bytes)
>>>     May  7 13:11:27 vpn-p1 charon: 12[ENC] parsed IKE_SA_INIT
>>>     request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V V V V ]
>>>     May  7 13:11:27 vpn-p1 charon: 12[IKE] received MS NT5
>>>     ISAKMPOAKLEY v9 vendor ID
>>>     May  7 13:11:27 vpn-p1 charon: 12[IKE] received MS-Negotiation
>>>     Discovery Capable vendor ID
>>>     May  7 13:11:27 vpn-p1 charon: 12[IKE] received
>>>     Vid-Initial-Contact vendor ID
>>>     May  7 13:11:27 vpn-p1 charon: 12[ENC] received unknown vendor
>>>     ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02
>>>     May  7 13:11:27 vpn-p1 charon: 12[IKE] 91.98.xxx.xxx is
>>>     initiating an IKE_SA
>>>     May  7 13:11:27 vpn-p1 charon: 12[CFG] received proposals:
>>>     IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048,
>>>     IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048,
>>>     IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_2048
>>>     May  7 13:11:27 vpn-p1 charon: 12[CFG] configured proposals:
>>>     IKE:AES_GCM_16_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_521,
>>>     IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_384,
>>>     IKE:AES_CBC_256/3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>>>     May  7 13:11:27 vpn-p1 charon: 12[IKE] remote host is behind NAT
>>>     May  7 13:11:27 vpn-p1 charon: 12[IKE] received proposals
>>>     inacceptable
>>>     May  7 13:11:27 vpn-p1 charon: 12[ENC] generating IKE_SA_INIT
>>>     response 0 [ N(NO_PROP) ]
>>>     May  7 13:11:27 vpn-p1 charon: 12[NET] sending packet: from
>>>     xxx.x.xx.92[500] to 91.98.xxx.xxx[500] (36 bytes)
>>>     May  7 13:11:28 vpn-p1 charon: 16[NET] received packet: from
>>>     91.98.xxx.xxx[500] to xxx.x.xx.92[500] (624 bytes)
>>>     May  7 13:11:28 vpn-p1 charon: 16[ENC] parsed IKE_SA_INIT
>>>     request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V V V V ]
>>>     May  7 13:11:28 vpn-p1 charon: 16[IKE] received MS NT5
>>>     ISAKMPOAKLEY v9 vendor ID
>>>     May  7 13:11:28 vpn-p1 charon: 16[IKE] received MS-Negotiation
>>>     Discovery Capable vendor ID
>>>     May  7 13:11:28 vpn-p1 charon: 16[IKE] received
>>>     Vid-Initial-Contact vendor ID
>>>     May  7 13:11:28 vpn-p1 charon: 16[ENC] received unknown vendor
>>>     ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02
>>>     May  7 13:11:28 vpn-p1 charon: 16[IKE] 91.98.xxx.xxx is
>>>     initiating an IKE_SA
>>>     May  7 13:11:28 vpn-p1 charon: 16[CFG] received proposals:
>>>     IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048,
>>>     IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048,
>>>     IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_2048
>>>     May  7 13:11:28 vpn-p1 charon: 16[CFG] configured proposals:
>>>     IKE:AES_GCM_16_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_521,
>>>     IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_384,
>>>     IKE:AES_CBC_256/3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>>>     May  7 13:11:28 vpn-p1 charon: 16[IKE] remote host is behind NAT
>>>     May  7 13:11:28 vpn-p1 charon: 16[IKE] received proposals
>>>     inacceptable
>>>     May  7 13:11:28 vpn-p1 charon: 16[ENC] generating IKE_SA_INIT
>>>     response 0 [ N(NO_PROP) ]
>>>     May  7 13:11:28 vpn-p1 charon: 16[NET] sending packet: from
>>>     xxx.x.xx.92[500] to 91.98.xxx.xxx[500] (36 bytes)
>>>
>>>     The Server's ipsec.conf is:
>>>
>>>     config setup
>>>     strictcrlpolicy=yes
>>>     uniqueids=never
>>>     conn roadwarrior
>>>     auto=add
>>>     compress=no
>>>     type=tunnel
>>>     keyexchange=ikev2
>>>     fragmentation=yes
>>>     forceencaps=yes
>>>     ike=aes256gcm16-sha256-ecp521,aes256-sha256-ecp384,aes256-3des-sha1-modp1024!
>>>     esp=aes256gcm16-sha256,aes256-3des-sha256-sha1!
>>>     dpdaction=clear
>>>     dpddelay=180s
>>>     rekey=no
>>>     left=%any
>>>     leftid=@${VPNHOST}
>>>     leftcert=cert.pem
>>>     leftsendcert=always
>>>     leftsubnet=0.0.0.0/0 <http://0.0.0.0/0>
>>>     right=%any
>>>     rightid=%any
>>>     rightauth=eap-radius
>>>     eap_identity=%any
>>>     rightdns=208.67.222.222,208.67.220.220
>>>     rightsourceip=${VPNIPPOOL}
>>>     rightsendcert=never
>>>
>>>     Have the supported ike/esp proposals somehow been changed
>>>     recently after a recent Windows 10 update?
>>>
>>>     I have made these changes on the Windows 10, after googling for
>>>     a solution:
>>>
>>>     - The firewall on Windows 10 is currently disabled.
>>>     - I have set NegotiateDH2048_AES256 = 1 in Regedit
>>>     - AssumeUDPEncapsulationContextOnSendRule = 2 in Regedit
>>>
>>>     I can't think of anything else I could do on the Windows 10 client.
>>>
>>>     According to my notes, these are the proposed protocols for
>>>     Windows 10:
>>>
>>>     # these ike and esp settings are tested on Mac 10.12, iOS 10 and
>>>     Windows 10
>>>     # iOS/Mac with appropriate configuration profiles use
>>>     AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_521
>>>     # Windows 10 uses
>>>     AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_384
>>>
>>>     Is there a website that translates
>>>     AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_384 into the
>>>     right naming for ipsec.conf so that I enter them under ike and
>>>     esp respectively? I can't quite make out if I have these
>>>     settings there or not.
>>>
>>>     If you have any other advice, please help me.
>>>
>>>     Many Thanks,
>>>
>>>
>>>
>>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180508/e6301f0d/attachment-0001.html>


More information about the Users mailing list