Windows 10 IPSec client connection problem
-
I have followed quite a few guides on setting up the Windows 10 native client with IKEv2, but I keep getting "Policy match error" regardless of what I change in the IPSec settings.
It seems that Windows requests:
Apr 4 23:20:27 charon 63327 10[CFG] <9> configured proposals: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048 Apr 4 23:20:27 charon 63327 10[CFG] <9> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 Apr 4 23:20:27 charon 63327 10[CFG] <9> no acceptable ENCRYPTION_ALGORITHM found Apr 4 23:20:27 charon 63327 10[CFG] <9> selecting proposal: Apr 4 23:20:27 charon 63327 10[IKE] <9> no matching proposal found, trying alternative config Apr 4 23:20:27 charon 63327 10[CFG] <9> candidate: xxx.yyy.119.130...0.0.0.0/0, ::/0, prio 1052 Apr 4 23:20:27 charon 63327 10[CFG] <9> candidate: xxx.yyy.119.130...0.0.0.0, prio 1052 Apr 4 23:20:27 charon 63327 10[CFG] <9> looking for IKEv2 configs for xxx.yyy.119.130...xxx.yyy.118.198 Apr 4 23:20:27 charon 63327 10[CFG] <9> configured proposals: IKE:AES_GCM_16_256/PRF_AES128_XCBC/MODP_3072, IKE:AES_GCM_16_192/PRF_AES128_XCBC/MODP_3072, IKE:AES_GCM_16_128/PRF_AES128_XCBC/MODP_3072, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_AES128_XCBC/MODP_3072 Apr 4 23:20:27 charon 63327 10[CFG] <9> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 Apr 4 23:20:27 charon 63327 10[CFG] <9> no acceptable PSEUDO_RANDOM_FUNCTION found Apr 4 23:20:27 charon 63327 10[CFG] <9> selecting proposal: Apr 4 23:20:27 charon 63327 10[CFG] <9> no acceptable ENCRYPTION_ALGORITHM found Apr 4 23:20:27 charon 63327 10[CFG] <9> selecting proposal: Apr 4 23:20:27 charon 63327 10[CFG] <9> no acceptable ENCRYPTION_ALGORITHM found Apr 4 23:20:27 charon 63327 10[CFG] <9> selecting proposal: Apr 4 23:20:27 charon 63327 10[CFG] <9> no acceptable ENCRYPTION_ALGORITHM found
I did however set these parameters in PowerShell:
Set-VpnConnectionIPsecConfiguration -ConnectionName "IPSec-cloud" ` >> -AuthenticationTransformConstants GCMAES256 -CipherTransformConstants GCMAES256 ` >> -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup Group14 -PfsGroup PFS2048 -PassThru Confirm Changing the Cryptography Settings. Do you want to continue? [Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): Y AuthenticationTransformConstants : GCMAES256 CipherTransformConstants : GCMAES256 DHGroup : Group14 IntegrityCheckMethod : SHA256 PfsGroup : PFS2048 EncryptionMethod : AES256
I've been at this for some days, but a connection eludes me.
This is not the place the rant about Windows, but there are reports of people for whom this works.
What could be the cause of this?
-
Try with this in the powershell command instead:
-EncryptionMethod GCMAES256
The phase 2 should not use a separate encryption method when using GCM.
Also note, Windows 10 will try and use PFS when it re-keys, even if it's set to none (unless they fixed it). My workaround for that is just to use PFS.
-
@bradsm87 Excellent, I'm making progress. After changing the EncryptionMethod as you suggested, I connect, but then get an error 87.
pfSense's log reports:
Apr 5 10:23:11 charon 63327 11[IKE] <88> IKE_SA (unnamed)[88] state change: CONNECTING => DESTROYING Apr 5 10:23:11 charon 63327 11[JOB] <88> deleting half open IKE_SA with xxx.yyy.118.198 after timeout Apr 5 10:22:41 charon 63327 13[NET] <88> sending packet: from xxx.yyy.119.130[500] to xxx.yyyy.118.198[500] (473 bytes) Apr 5 10:22:41 charon 63327 13[ENC] <88> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ] Apr 5 10:22:41 charon 63327 13[IKE] <88> sending cert request for "CN=Fastnet-CA-2, C=ZA, O=Abellard SS" Apr 5 10:22:41 charon 63327 13[IKE] <88> remote host is behind NAT Apr 5 10:22:41 charon 63327 13[CFG] <88> selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048 Apr 5 10:22:41 charon 63327 13[CFG] <88> configured proposals: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048 Apr 5 10:22:41 charon 63327 13[CFG] <88> received proposals: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048 Apr 5 10:22:41 charon 63327 13[CFG] <88> proposal matches Apr 5 10:22:41 charon 63327 13[CFG] <88> selecting proposal: Apr 5 10:22:41 charon 63327 13[IKE] <88> no matching proposal found, trying alternative config Apr 5 10:22:41 charon 63327 13[CFG] <88> candidate: xxx.yyy.119.130...0.0.0.0/0, ::/0, prio 1052 Apr 5 10:22:41 charon 63327 13[CFG] <88> candidate: xxx.yyy.119.130...0.0.0.0, prio 1052 Apr 5 10:22:41 charon 63327 13[CFG] <88> looking for IKEv2 configs for xxx.yyy.119.130...xxx.yyy.118.198
I don't see any way in which I can tell Windows to use NAT for IPSec, so I assume since it is detected, is does so automagically?
-
@bradsm87 Found the solution in this post.
A couple of reboots involved (it's windows after all!) and the connection now made successfully!
Here the text of the above link for reference.
when you try to connect is says "parameter is incorrect" then so the following:
1. Clear the Networking caches
Run windows cmd window (click windows start menu, type 'cmd', right click on 'Command Prompt' and select "Run as Administrator").
type command below
netsh int ip reset
then type
netsh int ipv6 reset
then type
netsh winsock reset
Restart your computer.
2. Reset Device Manager adaptors
Open Device Manager
Find Network Adapters
Uninstall WAN Miniport drivers (IKEv2, IP, IPv6, etc)
Click Action > Scan for hardware changes
The adapters you just uninstalled should come back
The VPN connection then works. -
One more thing though. If I opt to provide an ip address in the mobile client configuration, it is fixes for all mobile connections.
In the pre-shared key I can set an ip address pool to be provided for that specific key. However, if I set it, it seems to be ignored. If I remove the address from the client configuration, I get an error: Invalid payload received.
The documentation says:
How does one provide a different ip address for different clients to connect?
-
To answer my own question:
https://forum.netgate.com/topic/148452/virtual-address-pool-in-pre-shared-keys-is-not-used-for-ipsec/9