Windows 10 IPSec Roadwarrior Cert not working

anon45931963 · 23 May 2021 01:09

Hi,

I’ve been following the wikis to create an IPSec roadwarrior configuration.

I have had great success with macOS and iOS, I have a .mobileconfig profile that I can push out and iOS/macOS connects really great.

Windows however, is proving difficult. The exact same .p12 file that I am using for macOS and iOS successfully, I am importing into Windows certificate store.

I am following the instructions at the wiki here: https://wiki.ipfire.org/configuration/services/ipsec/example_configuration-_roadwarrior_with_windows

And yet with everything setup as per the wiki, Windows is refusing to use my certificate to authenticate. This is the error I am getting from Windows:

My CA root cert is in trusted root certificate store, and the client auth cert is in the computer/personal store as it should be.

I also cross checked with the strondSwan documentation here: Storing a Windows Machine Certificate :: strongSwan Documentation and here: Windows Client Configuration with Machine Certificates :: strongSwan Documentation

All is the same, yet it keeps telling me that error. Has anyone experienced this? What could it be?

I have a feeling that it is going to be something with the certificate?

I should mention this is the crypto profile of the Windows VPN:

 Set-VpnConnectionIPsecConfiguration -Name "WKITIPFire1" `

    -AuthenticationTransformConstants GCMAES128 `
    -CipherTransformConstants GCMAES128 `
    -DHGroup ECP384 `
    -IntegrityCheckMethod SHA256 `
    -PfsGroup ECP384 `
    -EncryptionMethod GCMAES128

And I have allowed ECP384 AES-128-GCM server side, looking at the stronSwan log it is matching up the proposed ciphers with configured ciphers so there does not appear to be a protocol missmatch, and indeed Windows gave a “protocol error” when there was one.

IPSec logs:

May 23 11:37:55 NF-WKIT-01 charon: 07[CFG] selected proposal: IKE:AES_GCM_16_128/PRF_HMAC_SHA2_256/ECP_384 
May 23 11:37:55 NF-WKIT-01 charon: 07[IKE] local host is behind NAT, sending keep alives 
May 23 11:37:55 NF-WKIT-01 charon: 07[IKE] remote host is behind NAT 
May 23 11:37:55 NF-WKIT-01 charon: 07[IKE] sending cert request for "C=AU, ST=NSW, L=Sydney, O=WKIT, OU=None, CN=WKIT CA, E=office@xxxx.com.au" 
May 23 11:37:55 NF-WKIT-01 charon: 07[ENC] 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) ] 
May 23 11:37:55 NF-WKIT-01 charon: 07[NET] sending packet: from 192.168.1.4[500] to 20.193.77.120[500] (313 bytes) 
May 23 11:38:12 NF-WKIT-01 charon: 07[IKE] sending keep alive to 20.193.77.120[500] 
May 23 11:38:12 NF-WKIT-01 charon: 09[IKE] sending keep alive to 20.193.77.120[500] 
May 23 11:38:15 NF-WKIT-01 charon: 14[IKE] sending keep alive to 20.193.77.120[500] 
May 23 11:38:15 NF-WKIT-01 charon: 13[IKE] sending keep alive to 20.193.77.120[500]

From what I can see in the logs, it has negotiated to use AES_GCM_16_128/PRF_HMAC_SHA2_256/ECP_384 just fine, and it is awaiting the presentation of a certificate by the WIndows client, and it seems that it just times out as I guess Windows is not selecting the certificate as it thinks it doesn’t have one.

Thanks

anon45931963 · 23 May 2021 03:00

I got it to work however I was unable to use the certificate issued for the macOS/iOS clients, I notice the certs in the wiki for windows are generated differently (particularly no SAN), and I had to fall back to the default crypto in the wiki, namely AES256CBC and MODP1024.

MODP1024 is not ideal at all, but at least I have a baseline connecting, so now I will pursue how I can harden this setup.

anon45931963 · 23 May 2021 03:42

Looking further, according to this: IKE failed to find valid machine certificate

My certificate should be using appropriate sized ECDSA key, and I can see that IPFire is generating certificate with RSA2048 which is what would appear to be stopping me from hardening up to ECP384.

I guess I will have to investigate making my own certificate instead on relying on the one manufactured by IPFire.

anon45931963 · 23 May 2021 14:27

Yup so I had to create new certs that are ECDSA384

And a client cert signed by them that is same.

I have it working now using this VPN profile:

Set-VpnConnectionIPsecConfiguration -Name "TestVPN" `
>>         -AuthenticationTransformConstants GCMAES256 `
>>         -CipherTransformConstants GCMAES256 `
>>         -DHGroup ECP384 `
>>         -IntegrityCheckMethod SHA384 `
>>         -PfsGroup ECP384 `
>>         -EncryptionMethod GCMAES256

or also this profile (I prefer this one as performance is better for negligible security difference):

Set-VpnConnectionIPsecConfiguration -Name "TestVPN" `
>>         -AuthenticationTransformConstants GCMAES128 `
>>         -CipherTransformConstants GCMAES128`
>>         -DHGroup ECP384 `
>>         -IntegrityCheckMethod SHA384 `
>>         -PfsGroup ECP384 `
>>         -EncryptionMethod GCMAES128

I think I will make a guide on the wiki for hardening W10 IKEv2/IPsec connections because the defaults that the wiki currently steers you to use are unfortunately stale crypto in 2021.

I’m not super enthused about using ECDSA, NSA backdoors and all, I’d prefer Ed25519 however options are super limited and this is about as good as you’ll get using Windows built-in VPN client with IPsec.