Add optional support for Windows 10 about algo HOT 45 CLOSED

According to this 29 September blog post, the most secure options are available only through Powershell, not the registry.

http://www.stevenjordan.net/2016/09/secure-ikev2-win-10.html
https://technet.microsoft.com/en-us/library/dn262642.aspx

from algo.

Thanks! This is incredibly useful information, and I never would have found it.

It looks like there is a somewhat undocumented NegotiateDH2048_AES256 registry key that enables modp2048 (Group 14) on RAS VPN clients. We can easily bundle a .reg file that users can double-click to set it. That improves things out of WeakDH range.

Of course, the overall setup will still use AES-CBC, non-ECC DH, and RSA certificates. It's a large document and I'm still processing some of it, but it looks like you might be able to improve this further to use AES-GCM, ECDSA, etc, especially in quick mode, if you configure a GPO policy. I'm not sure that is an option for us because of the way we deploy Algo VPN and our expected users.

Let me know if you think there is something else I can do besides ship a .reg file to set that key and upgrade the DH to modp2048!

Here's the same document hosted at Microsoft:
http://download.microsoft.com/download/A/9/F/A9FD7E2D-023B-4925-A62F-58A7F1A6BD47/Microsoft%20Windows%208%20Windows%20Server%202012%20Supplemental%20Admin%20Guidance%20IPsec%20VPN%20Client.docx

from algo.

He was only showing an example of what PFS accept/reject looks like. Thermi has his own install of strongSwan to play with. He's on their development team :-D.

from algo.

Windows appears to offer the following for IKE, none of which looks very encouraging:

12[CFG] received proposals:
IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
IKE:3DES_CBC/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024,
IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, 
IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024,
IKE:AES_CBC_192/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
IKE:AES_CBC_192/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
IKE:AES_CBC_192/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024,
IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024

If you leave StrongSwan and Windows 10 to their defaults, here's how the exchange turns out:

11[CFG] received proposals: IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:3DES_CBC/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, IKE:AES_CBC_192/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_192/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_192/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024
11[CFG] configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536, IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/HMAC_MD5_96/HMAC_SHA1_96/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/AES_XCBC_96/PRF_HMAC_MD5/PRF_HMAC_SHA1/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/MODP_2048/MODP_2048_224/MODP_2048_256/MODP_1536/MODP_3072/MODP_4096/MODP_8192/MODP_1024/MODP_1024_160/ECP_256/ECP_384/ECP_521/ECP_224/ECP_192/ECP_224_BP/ECP_256_BP/ECP_384_BP/ECP_512_BP, IKE:AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/PRF_HMAC_MD5/PRF_HMAC_SHA1/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/MODP_2048/MODP_2048_224/MODP_2048_256/MODP_1536/MODP_3072/MODP_4096/MODP_8192/MODP_1024/MODP_1024_160/ECP_256/ECP_384/ECP_521/ECP_224/ECP_192/ECP_224_BP/ECP_256_BP/ECP_384_BP/ECP_512_BP
11[CFG] selected proposal: IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 !!!

This is confirmed by Default Encryption Settings for the Microsoft L2TP/IPSec Virtual Private Network Client. Windows 7-10 prefer 3DES and 1024-bit DH for their IKE and L2TP VPN connections. EDIT: This cipher suite will use PFS, an earlier version of this issue claimed it did not.

The best configuration for StrongSwan would be the cipher suite below, which forces Windows clients up to the best suite they offer. It's still got AES-CBC and 1024-bit DH, but there's nothing you can do about that. I maxed SHA-2 at 256-bits because I think anything higher is overkill:

aes256-sha2_256-prfsha256-modp1024

Now that I've worked out the cipher support (which we'll have to hide behind a user configurable option) there's still some issues to work out with regard to certificate storage on Windows. Windows can't find the right certificates to use to complete the exchange and it has something to do with how I'm loading them. See StrongSwan's documentation on Windows 7+. I have the feeling we'll have to downgrade from ECC to RSA certificates.

I'm still holding out hope I can figure out a different way to configure Windows 10, since this support article claims it supports better ciphers, like aesgcm256, sha2, and ecdhp256. EDIT: Unfortunately, this support doc only applies to the VPN in the Windows Firewall, which does not support config mode or IKEv2. We can't use the Windows Firewall so we're stuck with modp1024 et al.

from algo.

The LibreSwan documentation was a little bit more clear on the certificate requirements. In each of the cases below, our certificates were already correctly generated by easy-rsa-ipsec (thank you ValdikSS!)

• The VPN gateway's certificate must have its DNS name as SubjectAltname (SAN) in the certificate. The client then must connect to the VPN using the DNS name. Alternately, the client can connect using the IP if the SAN contains the IP address of the gateway.
• The VPN gateway's certificate must have the Digital Signature and Key Encipherment KU extensions if the SAN and CN use the same, full DNS name. It must also have the serverAuth EKU extension. It may have also have the clientAuth EKU extension.

To import the certs, place the user certificate in LocalMachine->Personal Certificates and the CA certificate to LocalMachine->Trusted Root Certification Authorities. You also need to open the VPN adapter in the network control panel, right click and choose properties, then go to Security->Authentication->Use machine certificates. I would probably choose "Data Encryption: Maximum strength encryption" for good measure while you are there...

In the process of working this out, I discovered that the cipher situation for ESP is even worse than IKE: it only supports SHA-1. Here are the advertised ciphers by Windows 10 for ESP:

13[CFG] received proposals:
ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ,
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ,
ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ,
ESP:DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ,
ESP:NULL/HMAC_SHA1_96/NO_EXT_SEQ

The default ESP cipher suite is 3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ 👎

Based on the advertised suites, this means the best setting we can get for ESP is:

aes256-sha1-modp1024

Now to retry all of this with ECC certificates and see if it fails...

from algo.

Yep, I get an error from Windows that says IKE failed to find valid machine certificate... when I redo everything with the original ECDSA certificate setup. It looks like Windows only works with RSA certificates.

@gunph1ld We need to make a configuration option that asks "Do you want to support Windows VPN clients (enables weak ciphers)? y/n?" Selecting it should do the following:

1. Change easy-rsa-ipsec to build RSA certificates and ipsec.secrets to use an RSA certificate
2. Add the extra set of ciphers to the IKE and ESP parameters in ipsec.conf

from algo.

You don't necessarily have to switch from ECDSA to RSA. You can just run them side by side.

from algo.

Is this at all helpful?

https://www.niap-ccevs.org/st/st_vid10529-agd.pdf

Section 2.2.2.2 Configuring DH Group 14 and AES256 for IKEv2 (p.21)

from algo.

That's actually superbly helpful, if it works.

from algo.

Let me know if you think there is something else I can do besides ship a .reg file to set that key and upgrade the DH to modp2048!

If your goal is to avoid shipping a file, you could just tell Windows 10 users to run this as an administrator:

reg add HKLM\System\CurrentControlSet\Services\Rasman\Parameters /v NegotiateDH2048_AES256 /t REG_DWORD /d 1 /f

from algo.

[...] , especially in quick mode, [...]

It has to be config mode. If quick mode is used, no "virtual" IP and no DNS servers are assigned, making the whole set up useless. Only because Windows supports it doesn't mean it's meaningful. The ciphers do not differ between the modes, though.

from algo.

$250 bounty! Submit a pull request and email [email protected] to claim it. Partial solutions may be rewarded.

from algo.

Hi all, gave the latest commit of the win10_support branch a try again today, and was able to get a successful connection to a Digital Ocean droplet through Algo.

There was a curiosity that a MacOS client wasn't able to establish a connection until AFTER a Windows 10 box had tried, I shall attempt to reproduce it later with a new droplet / test and see if if it's a repeatable issue or not.

Thanks @dguido, @gunph1ld, and everyone else for negotiating the minefield of Windows IKEv2 support and getting a working deployment available :)

from algo.

@andyeff As I know It's a restriction of IKEv2. You can't use more then 1 clients behind 1 IP-NAT (say 1 router)

from algo.

@gunph1ld Ah, this was attempting to connect from a Mac before even trying with Windows, rather than trying to have two stable connections up at once.

I'll fire up another droplet and confirm now. I certainly had no problems going Mac-first over the last couple of days so maybe it was a freak networking issue locally.

from algo.

@gunph1ld

As I know It's a restriction of IKEv2. You can't use more then 1 clients behind 1 IP-NAT (say 1 router)

That's absolutely wrong. It always works, except when you use naive IPsec with transport mode (and L2TP), then you need to fix it on the server side by using CONNMARK and other fun and semi-complex stuff, or when the NAT router implements broken IPsec "passthrough" (basically NATS all local IKE and NAT-T traffic to port 500), which prevents the router itself from differentiating the two data streams for the two different clients.

from algo.

Then, sorry me, I was wrong, I was thinking about the transport mode. Thanks @Thermi

from algo.

@gunph1ld New droplet just worked fine first time with MacOS, so as far as I can tell this is now a valid easy deployment VPN for Win10 + Mac (on Digitalocean at least). Thanks!

from algo.

Does this doc provide any useful info regarding ECDSA certs? Also seems to suggest GCM may be doable in quick mode.

https://www.niap-ccevs.org/st/st_vid10746-agd.pdf

edit: apologies if it's bad form to add comments to closed issues rather than creating a new one. I'm a rookie.

from algo.

Don't use quick mode. Use config mode. You need to assign virtual IPs to initiators. That forces the use of config mode.

from algo.

This is the current suggested command to set up VPN.

Set-VpnConnectionIPsecConfiguration -ConnectionName "Algo" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup Group14 -PfsGroup none

For Windows 10, https://technet.microsoft.com/itpro/powershell/windows/vpnclient/set-vpnconnectionipsecconfiguration suggests that we could utilize some stronger options.

Maybe,

• -DHGroup ECP256
• -AuthenticationTransformConstants GCMAES128
• -CipherTransformConstants GCMAES128

Not clear about PfsGroup.

from algo.

I noticed this as well while I was making my IPSEC Crypto Wall of Shame. Worth a second look.

from algo.

You should definitively use PFS, preferably with a large (strong) group.

from algo.

This might also make it unnecessary to have a Windows downgrade based on the ciphers picked.

@dguido per @sanitybit 's registry setting above, the following should be the PowerShell equivalent.

If (!(Test-Path "HKLM:\System\CurrentControlSet\Services\Rasman\Parameters")) {
New-Item -Path "HKLM:\System\CurrentControlSet\Services\Rasman\Parameters" | Out-Null
}
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\Rasman\Parameters" -Name "NegotiateDH2048_AES256" -Type DWord -Value 1

from algo.

We couldn't get this to work the last time we tried. Can someone grab a copy of Windows 10 Creators Update and try enabling the ciphers from #9 (comment) ? You'll want to setup Algo in the default configuration and see if you can get it to connect.

from algo.

I don't believe you need to configure PFS in IKEv2, as it is implicitly FS in all its rekeying.
Explicit PFS group is for IKEv1. StrongSWAN may ignore this anyway with IKEv2 setup.

Ill grab the creators update and try with the strong ciphers. I'm keen to get GCM working hardware acceleration e/d. I noticed it was defaulting to CBC.

from algo.

Getting policy mismatch when I update those - I am on build 15063.138 which is creator's update :)
Digital Ocean

from algo.

@MiWCryptAnalytics There's no implicit PFS with either IKEv1 or IKev2. PFS requres an explicit KE payload from the peer that initiates the rekeying. PFS only applies to new CHILD_SAs, after the initial one (the first one) was created. I'm testing either combination of proposals now.

from algo.

When the server only supports PFS, but the client doesn't support it:

Sun, 2017-04-16 19:11 27[CFG] <larval-drop-test|12> selecting proposal:
Sun, 2017-04-16 19:11 27[CFG] <larval-drop-test|12>   no acceptable DIFFIE_HELLMAN_GROUP found
Sun, 2017-04-16 19:11 27[CFG] <larval-drop-test|12> received proposals: ESP:CHACHA20_POLY1305_256/NO_EXT_SEQ
Sun, 2017-04-16 19:11 27[CFG] <larval-drop-test|12> configured proposals: ESP:CHACHA20_POLY1305_256/NEWHOPE_128/NO_EXT_SEQ
Sun, 2017-04-16 19:11 27[IKE] <larval-drop-test|12> no acceptable proposal found
Sun, 2017-04-16 19:11 27[IKE] <larval-drop-test|12> failed to establish CHILD_SA, keeping IKE_SA
Sun, 2017-04-16 19:11 27[ENC] <larval-drop-test|12> generating CREATE_CHILD_SA response 5 [ N(NO_PROP) ]

When the client supports it, but the server doesn't:

Sun, 2017-04-16 19:13 16[NET] <larval-drop-test|13> received packet: from 2a02:8071:9288:7d00:152e:c6ca:a545:f543[4500] to 2a03:4000:13:10a::1[4500] (1228 bytes)
Sun, 2017-04-16 19:13 16[ENC] <larval-drop-test|13> parsed CREATE_CHILD_SA request 2 [ EF(1/2) ]
Sun, 2017-04-16 19:13 16[ENC] <larval-drop-test|13> received fragment #1 of 2, waiting for complete IKE message
Sun, 2017-04-16 19:13 23[NET] <larval-drop-test|13> received packet: from 2a02:8071:9288:7d00:152e:c6ca:a545:f543[4500] to 2a03:4000:13:10a::1[4500] (922 bytes)
Sun, 2017-04-16 19:13 23[ENC] <larval-drop-test|13> parsed CREATE_CHILD_SA request 2 [ EF(2/2) ]
Sun, 2017-04-16 19:13 23[ENC] <larval-drop-test|13> received fragment #2 of 2, reassembling fragmented IKE message
Sun, 2017-04-16 19:13 23[ENC] <larval-drop-test|13> parsed CREATE_CHILD_SA request 2 [ N(REKEY_SA) N(USE_TRANSP) SA No KE TSi TSr ]
Sun, 2017-04-16 19:13 23[CFG] <larval-drop-test|13> selecting proposal:
Sun, 2017-04-16 19:13 23[CFG] <larval-drop-test|13>   no acceptable DIFFIE_HELLMAN_GROUP found
Sun, 2017-04-16 19:13 23[CFG] <larval-drop-test|13> received proposals: ESP:CHACHA20_POLY1305_256/NEWHOPE_128/NO_EXT_SEQ
Sun, 2017-04-16 19:13 23[CFG] <larval-drop-test|13> configured proposals: ESP:CHACHA20_POLY1305_256/NO_EXT_SEQ
Sun, 2017-04-16 19:13 23[IKE] <larval-drop-test|13> no acceptable proposal found
Sun, 2017-04-16 19:13 23[IKE] <larval-drop-test|13> failed to establish CHILD_SA, keeping IKE_SA
Sun, 2017-04-16 19:13 23[ENC] <larval-drop-test|13> generating CREATE_CHILD_SA response 2 [ N(NO_PROP) ]

Replace "server" with "responder" and "client" with "initiator", if you prefer proper IPsec speak.

from algo.

from algo.

@jauderho I'm not running Algo. I got my own boxes with the most recent version of strongSwan to play with. I used chacha20poly1305, because (as one could tell by the name), I just repurposed an existing connection to test this specific scenario.
Regarding your cipher suites under compat: "aes128gcm16-sha2_512-prfsha512-ecp256" will never use sha2_512 as HMAC, because aes128gcm16 already provides authenticity and sha2_512 is implicitely not used by any peer. Using any specified HMAC when an AEAD algorithm is used is invalid behaviour.
Same with aes128gcm16-sha2_512-ecp256.
With aes128-sha2_256-prfsha256-modp2048, you'll have problems with HMAC-SHA2-256 ambiguity with peer that implement the draft of the SHA-2 for IPsec specification (96 bit truncation in the draft vs 128 bit truncation in the final version. That problem is more than a decade old).

@dguido Not on the dev team, but providing the majority of the support.

from algo.

@Thermi to be clear, I didn't pick that current cipher list but merely referencing what is in place today. I think @dguido would welcome suggestions to fix it up. =)

I believe there was a recent switch to SHA512 instead SHA256 due to what you mention. Maybe aes128-sha2_256-prfsha256-modp2048 should be dropped or changed to aes128-sha2_512-prfsha256-modp2048 <-- will this even work?

See https://github.com/trailofbits/algo/blob/master/roles/vpn/defaults/main.yml

from algo.

Oh interesting. Thanks for the tip Thermi! Yes, I guess we need to fixup the default and compat ciphers list then.

I guess something like this? I haven't tested this. I'm just running out the door now!

ciphers:
  defaults:
    ike: aes128gcm16-prfsha512-ecp256!
    esp: aes128gcm16-ecp256!
  compat:
    ike: aes128gcm16-prfsha512-ecp256,aes128-sha2_512-prfsha512-ecp256,aes128-sha2_512-prfsha512-modp2048!
    esp: aes128gcm16-ecp256,aes128-sha2_512-ecp256,aes128-sha2_512-prfsha512-modp2048!

I really wish someone could figure out how to get Windows to use the ciphers in default...

from algo.

@jauderho You could change to either sha2_384, sha2_512 or use an AEAD algorithm (preferred!).

@dguido Looks good from my side.

from algo.

I'll try to get to it if I find some time.

@dguido There's a great writeup about AEADs by agl if you have not previously seen it. https://www.imperialviolet.org/2015/05/16/aeads.html

from algo.

I've just installed an algo VPN on DigitalOcean and I'm unable to connect from my Surface Pro 4 running Windows 10 (w/o Creator's Update). Algo works from my Android.
I thought Windows 10 was supported?

Apr 23 17:25:44 algo charon: 13[IKE] IKE_SA (unnamed)[45] state change: CREATED => CONNECTING
Apr 23 17:25:44 algo charon: 13[CFG] selecting proposal:
Apr 23 17:25:44 algo charon: 13[CFG]   no acceptable ENCRYPTION_ALGORITHM found
Apr 23 17:25:44 algo charon: 13[CFG] selecting proposal:
Apr 23 17:25:44 algo charon: 13[CFG]   no acceptable PSEUDO_RANDOM_FUNCTION found
Apr 23 17:25:44 algo charon: 13[CFG] selecting proposal:
Apr 23 17:25:44 algo charon: 13[CFG]   no acceptable PSEUDO_RANDOM_FUNCTION found
Apr 23 17:25:44 algo charon: 13[CFG] received proposals: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
Apr 23 17:25:44 algo charon: 13[CFG] configured proposals: IKE:AES_GCM_16_128/PRF_HMAC_SHA2_512/ECP_256, IKE:AES_CBC_128/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/ECP_256, IKE:AES_CBC_128/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
Apr 23 17:25:44 algo charon: 13[IKE] remote host is behind NAT
Apr 23 17:25:44 algo charon: 13[IKE] received proposals inacceptable

from algo.

We just committed #464. This PR fixes a few issues for Windows clients:

1. ECDSA certificates replace RSA certificates
2. IKE: SHA2-384 integrity checking replaces SHA2-256 (avoid 96-bit truncation issue)
3. IKE & ESP: ECP256 diffie hellman replaces modp2048 (no more RSA!)

There are 2 issues that prevent Windows from using the default cipher suite:

1. We can't find a way to get IKE to use AES-GCM
2. The latest version of Windows 10 does not support SHA2-512

Windows connections should work again if anyone wants to try it now.

from algo.

I've changed my ike setup in ipsec.conf according to #464. I've removed the VPN connection in Windows and updated my script according to #464. I've rerun the script and still can't connect:

Apr 23 21:45:21 algo charon: 14[IKE] 95.232.127.134 is initiating an IKE_SA
Apr 23 21:45:21 algo charon: 14[IKE] IKE_SA (unnamed)[5] state change: CREATED => CONNECTING
Apr 23 21:45:21 algo charon: 14[CFG] selecting proposal:
Apr 23 21:45:21 algo charon: 14[CFG]   no acceptable ENCRYPTION_ALGORITHM found
Apr 23 21:45:21 algo charon: 14[CFG] selecting proposal:
Apr 23 21:45:21 algo charon: 14[CFG]   no acceptable PSEUDO_RANDOM_FUNCTION found
Apr 23 21:45:21 algo charon: 14[CFG] selecting proposal:
Apr 23 21:45:21 algo charon: 14[CFG]   no acceptable PSEUDO_RANDOM_FUNCTION found
Apr 23 21:45:21 algo charon: 14[CFG] received proposals: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
Apr 23 21:45:21 algo charon: 14[CFG] configured proposals: IKE:AES_GCM_16_128/PRF_HMAC_SHA2_512/ECP_256, IKE:AES_CBC_128/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/ECP_256, IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_256
Apr 23 21:45:21 algo charon: 14[IKE] remote host is behind NAT
Apr 23 21:45:21 algo charon: 14[IKE] received proposals inacceptable

Are these changes enough to test #464 or do I need to redeploy?

from algo.

felipekk I think you made a typo when you updated your local PowerShell script. Make sure you replace the SHA2-256 with SHA2-384.

from algo.

@dguido Please note that the script in #464 does not specify SHA2-384. I've manually changed my PowerShell script to:
-AuthenticationTransformConstants GCMAES128 -CipherTransformConstants GCMAES128 -EncryptionMethod AES128 -IntegrityCheckMethod SHA384 -DHGroup ECP256 -PfsGroup none
This time I've got a different error: "IKE failed to find valid machine certificate".

Apr 23 21:59:49 algo charon: 11[IKE] 95.232.127.134 is initiating an IKE_SA
Apr 23 21:59:49 algo charon: 11[IKE] IKE_SA (unnamed)[10] state change: CREATED => CONNECTING
Apr 23 21:59:49 algo charon: 11[CFG] selecting proposal:
Apr 23 21:59:49 algo charon: 11[CFG]   no acceptable ENCRYPTION_ALGORITHM found
Apr 23 21:59:49 algo charon: 11[CFG] selecting proposal:
Apr 23 21:59:49 algo charon: 11[CFG]   no acceptable PSEUDO_RANDOM_FUNCTION found
Apr 23 21:59:49 algo charon: 11[CFG] selecting proposal:
Apr 23 21:59:49 algo charon: 11[CFG]   proposal matches
Apr 23 21:59:49 algo charon: 11[CFG] received proposals: IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_256
Apr 23 21:59:49 algo charon: 11[CFG] configured proposals: IKE:AES_GCM_16_128/PRF_HMAC_SHA2_512/ECP_256, IKE:AES_CBC_128/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/ECP_256, IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_256
Apr 23 21:59:49 algo charon: 11[CFG] selected proposal: IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_256
Apr 23 21:59:49 algo charon: 11[IKE] remote host is behind NAT

from algo.

Maybe you and I are not looking at the same script. #464 uses the following line:

Set-VpnConnectionIPsecConfiguration -ConnectionName "Algo VPN {{ IP_subject_alt_name }} IKEv2" -AuthenticationTransformConstants GCMAES128 -CipherTransformConstants GCMAES128 -EncryptionMethod AES128 -IntegrityCheckMethod SHA384 -DHGroup ECP256 -PfsGroup none

Regardless, your current problem now is that you didn't install the CA certificate. Step 2 from the Windows clients directions indicates: "Import the CA certificate to the local machine Trusted Root certificate store."

from algo.

We were not looking at the same script, sorry! I was looking at this.
Yeah I figured it's a different problem now, but I don't know what it is since I see the certificate in the Trusted Root Certification Authorities for Local Machine. I've tried removing and re-importing it but no dice.

from algo.

@dguido
"IKE & ESP: ECP256 diffie hellman replaces modp2048 (no more RSA!)"
MODP is DH and ECP is DH over an elliptic curve. Neither of those two have anything to do with RSA. The key exchange method and the algorithm and key lengths the certificate use are independent of each other and you can combine any type of key exchange (MODP, ECP, ECP over Brainpool Curves, curve25519, NTRU, NEWHOPE) with any type of certificate (RSA, DSA/ELGAMAL, ECDSA, BLISS).
This comment's purpose is just to correct this piece of misinformation.

from algo.

Thanks! My vocabulary was a little sloppy, my bad. :-P

from algo.

Just FYI, I've redeployed and it works, I'm on Windows 10 without Creators Update.

from algo.