VPN Reconnect in Windows 7 RC - redux

Update 22.04.2015, comment from Jason Jones:

we fixed the problem with trusting all Root certificates for IKEv2 machine authentication with the following PowerShell cmdlet/switch:

Set-VpnAuthProtocol -RootCertificateNameToAccept

https://technet.microsoft.com/en-us/library/hh918382.aspx

 This can be used to specify an internal trusted Root CA when validating IKEv2 machine certs and negates the need to “clean” the Trusted Roots Cert store on the RRAS server

------------

Sometime ago we’ve taken a quick look at the new VPN feature from Windows 7 Beta, Agile VPN aka today as VPN Reconnect or IKEv2.
Now Windows 7 is an RC, and some enhancements to the VPN Reconnect feature were made:
http://blogs.technet.com/rrasblog/archive/2009/05/11/enhancements-to-vpn-reconnect-in-w7-rc.aspx

Probably the most visible enhancement for the VPN user, is the validation of the VPN server’s machine certificate by the VPN client for better security. This not only makes the IKEv2 client in Windows 7 RC RFC compliant with section 2.16 of RFC4306 when EAP authentication methods are used, but also prevents offline dictionary attacks against user credentials when EAP-MSCHAPv2 is used for user authentication, as this validation takes place before user credentials are sent. As has been noted by Andreas Steffen from strongSwan, the Windows 7 Beta IKEv2 VPN client, due to the violation of section 2.16 of RFC4306, was susceptible to offline dictionary attacks against user credentials when EAP-MSCHAPv2 is used for user authentication.

So currently, with EAP methods for user authentication(EAP-MSCHAPv2, PEAP-EAP-MSCHAPv2, EAP-TLS, PEAP-EAP-TLS) or machine authentication with certificates, the IKEv2 VPN client in Windows 7 RC always, by default, validates the VPN server’s machine certificate(checking the server’s name and the EKU field on that certificate too).
EAP-MSCHAPv2, PEAP-EAP-MSCHAPv2, EAP-TLS, PEAP-EAP-TLS are mutual and key derivation authentication methods.
There is a draft called An Extension for EAP-Only Authentication in IKEv2(as writing version 06), which, if it passes the draft status, may allow the stronger EAP methods that establish a shared secret key(obviously not EAP-MSCHAPv2 –:) ) to be used without public key signature based responder authentication with IKEv2, as these stronger EAP methods can “take care” of themselves, being used on wireless LANs and offering mutual authentication and protection against offline dictionary attacks(for passive and active MITMs).

What this validation means ?
First basic stuff: the server’s certificate to be issued by a trusted CA(within the Trusted Root Certification Authorities the Computer Certificate Store), to be valid(not expired).
Next, similar with the validation introduced in Windows Vista for the L2TP/IPsec VPN client called Verify the Name and Usage attributes of the server's certificate, the IKEv2 VPN client in Windows 7 RC checks the name on the VPN server’s certificate and the EKU field on that certificate. But the comparison stops here, as the L2TP/IPsec VPN client has a silly and potentially dangerous behavior in respect with the validation process in certain circumstances, and you cannot disable the new checks on the VPN connection itself for VPN Reconnect like it is possible for the L2TP/IPsec connection.

Note: You can disable the name and EKU checks for IKEv2 VPN connections within Windows 7 RC using the DisableIKENameEkuCheck registry value, see Microsoft’s KB 926182(although this is written for L2TP/IPsec and Vista, it works for IKEv2 and Windows 7 RC too). Not only is highly recommended to not do so, but if you do so, this appears to be a global value, so you will disable the extra checks for every L2TP/IPsec and IKEv2 VPN connections that are configured on the user’s machine(including installed CMAK profiles, CMAK profiles created on Windows Server 2008 R2 RC).
This reg value only disables the name and EKU checks, the CA that issued the certificate still have to be trusted, and the certificate valid(not expired).
Apparently when you use a CMAK profile and set the DisableIKENameEkuCheck value to 0 on that profile, according to, as writing the linked Microsoft document, it should disable the EKU check on the server’s certificate. However, not only I could not make it work this setting when using the CMAK on Windows Server 2008 R2 RC and installed the created CMAK profile on Windows 7 RC, the check still applying for the IKEv2 CMAK profile, but instead I’ve successfully applied this value for a CMAK profile using L2TP/IPsec, which disabled both the name and EKU checks for this CMAK profile although that Microsoft document claims this value only applies to IKEv2 connections. The name and EKU checks are enabled by default on CMAK profiles created on Windows Server 2008 R2 RC for IKEv2 and L2TP/IPsec connections.

So what exactly these name and EKU validations mean ? :)

First, we expect the VPN server’s certificate to be issued by a trusted CA, so we add this CA’s cert within the Trusted Root Certification Authorities the Computer Certificate Store on the client(you need admin privileges for that):

Next, say we configure an IKEv2 VPN connection on the client’s machine:

And we specify the host name or IP address of the IKEv2 VPN server on this VPN connection:

If so, the IKEv2 VPN client in Windows 7 RC expects to “find” this host name or IP address on the IKEv2 VPN server’s certificate.
But where appears this name on the IKEv2 VPN server’s certificate ?
Let’s take a look at some certificates.

Name Check
This certificate for example, was issued to the host name we configured on our VPN connection:

If we take a look at the details of this certificate, at the Subject, we can see the CN is the same with the host name we configured on our VPN connection:

But this certificate also contains a Subject Alternative Name, as can be seen the DNS Name from there is the same host name we configured on our VPN connection:

Another certificate, this one was issued to the IP address configured on our VPN connection:

The Subject of this certificate has the CN the same with the IP address configured on our VPN connection(there isn’t a Subject Alternative Name):

Another certificate:

The Subject of this certificate has the CN the same with the host name configured on our VPN connection:

But also there is a Subject Alternative Name, containing a DNS Name and an IP address(both match our VPN server’s address):

Another certificate:

The Subject of this certificate has the CN the same with the IP address configured on our VPN connection:

But also there is a Subject Alternative Name, containing a DNS Name and an IP address(both match our VPN server’s address):

So, as we seen, we may have some variations. Likely in practice, it’s not very practical to issue certificates to IP addresses, so probably host names will appear on the IKEv2 VPN server’s certificate.

In order to analyze these variations, as there is little information as currently writing about them versus the checks done by the Windows 7 RC IKEv2 client, I’ve setup in addition to a Windows Server 2008 Enterprise CA, two test OpenSSL CAs, issued over 100 certificates(part of other checks), and made tryouts.
To quickly work with the OpenSSL CAs, I’ve used pretty much the same CA used here, modifying a little bit the openssl.cfg this time, to contain the desired X.509 V3 extensions to be added when the CA signs the VPN server’s certificate request:

So to issue a certificate for the server, when I sign the server’s request, I specify the desired extensions to be added to the server’s certificate:

openssl req -config openssl.cfg -new -keyout keys/rras1.key -out reqs/rras1.csr
openssl ca -policy policy_anything -config openssl.cfg -extensions my_server_1 -cert newcerts/ca.pem -in reqs/rras1.csr -keyfile keys/ca.key -out newcerts/rras1.pem
openssl pkcs12 -export -in newcerts/rras1.pem -inkey keys/rras1.key -certfile newcerts/ca.pem -out export/rras1.p12

All of the certificates were issued having the Key Usage and Basic Constraints fields like so:
- Key Usage = Digital Signature, Key Encipherment
- Basic Constraints: Subject Type=End Entity

The results I currently obtained for the IKEv2 server’s name validation on the Windows 7 RC IKEv2 client:

- if the server’s certificate contains only the CN field, this can be either a host name or IP address. If it’s a host name, this host name should be configured as the VPN server’s address on the client’s VPN connection. If it’s an IP address, this IP address should be configured as the VPN server’s address on the client’s VPN connection. The same thing is true for the SSTP VPN connections and the validation of server’s certificate part of the SSL authentication.

- if the server’s certificate contains both CN(set to host name) and SAN(set to DNS Name) fields, then the client verifies the DNS Name from the SAN field. So this DNS name should be configured as the VPN server’s address on the client’s VPN connection. The same thing is true for the SSTP and for L2TP/IPsec VPN connections for the validation of server’s certificate part of the SSL authentication respectively part of the machine(IKE) authentication.

- if the server’s certificate contains both CN(set to host name) and SAN(set to IP address) fields, then the client verifies the host name from the CN field. So this host name should be configured as the VPN server’s address on the client’s VPN connection. The same thing is true for the SSTP and for L2TP/IPsec VPN connections for the validation of server’s certificate part of the SSL authentication respectively part of the machine(IKE) authentication.

- if the server’s certificate contains both CN(set to IP address) and SAN(set to IP address) fields, then the client verifies the IP address from the CN field. So this IP address should be configured as the VPN server’s address on the client’s VPN connection. The same thing is true for the SSTP VPN connections and the validation of server’s certificate part of the SSL authentication.

- if the server’s certificate contains both CN(set to IP address) and SAN(set DNS Name) fields, then the client verifies the DNS Name from the SAN field. So this DNS Name should be configured as the VPN server’s address on the client’s VPN connection. The same thing is true for the SSTP VPN connections and the validation of server’s certificate part of the SSL authentication.

- if the server’s certificate contains both CN(set to host name) and SAN(containing a DNS Name and an IP Address) fields, then the client verifies the DNS Name from the SAN field. So this DNS name should be configured as the VPN server’s address on the client’s VPN connection. The same thing is true for the SSTP and for L2TP/IPsec VPN connections for the validation of server’s certificate part of the SSL authentication respectively part of the machine(IKE) authentication.

- if the server’s certificate contains both CN(set to IP address) and SAN(containing a DNS Name and an IP Address) fields, then the client verifies the DNS Name from the SAN field. So this DNS name should be configured as the VPN server’s address on the client’s VPN connection. The same thing is true for the SSTP and for L2TP/IPsec VPN connections for the validation of server’s certificate part of the SSL authentication respectively part of the machine(IKE) authentication.

Note:  The L2TP/IPsec validation process part of IKE(machine) authentication has a “special” behavior in a negative sense, that is, if you configure an IP address as the VPN server’s address on the client’s VPN connection, this, according to my tests, is equivalent to deselecting the Verify the Name and Usage attributes of the server's certificate option, basically the L2TP/IPsec VPN Windows 7 RC VPN client stops checking the server’s name or the EKU field from the server’s certificate. This is also true for CMAK profiles created on Windows Server 2008 R2 RC.

Note: If the SAN contains multiple DNS Names, then the IKEv2, SSTP and L2TP/IPsec VPN clients from Windows 7 RC are able to “consume” all these entries, that is, any of these DNS names can be configured as the VPN server’s address on the client’s VPN connection(for example, for SSTP, the client's SSL Hello message contains the Extension: server_name with the name of the server configured on the VPN connection).

Note: In practice, if the server’s certificate contains a SAN DNS Name entry it is probable that the DNS Name to be the same with the CN(if the CN is a host name).

This table summarize the currently obtained results for the IKEv2 server’s name validation for the Windows 7 RC IKEv2 client:

Note: The above table also applies for SSTP and L2TP/IPsec VPN connections and the validation done by the Windows 7 RC VPN client over the name from the server’s certificate during the SSL authentication(for SSTP) and respectively IKE authentication(machine authentication for L2TP/IPsec). As an extra note, remember the L2TP/IPsec VPN client’s behavior when you configure an IP address as the VPN server’s address on the client’s VPN connection.

EKU Field Check
Let’s take a look at some certificates and their EKU fields:

The results I currently obtained for the IKEv2 server’s certificate EKU field validation on the Windows 7 RC IKEv2 client:

Normally, “server” certificates contained certain EKU field values, so I’ve tried to mix these values to see what I will get.

The table bellow summarize the accepted EKU field by the Windows 7 RC IKEv2 VPN client during tests:

IP security IKE intermediate =  OID: 1.3.6.1.5.5.8.2.2
Server Authentication  = OID: 1.3.6.1.5.5.7.3.1
Client Authentication  = OID: 1.3.6.1.5.5.7.3.2
No EKU = All Purposes EKU(sort of)

Note: The above table also applies for SSTP and L2TP/IPsec VPN connections and the validation done by the Windows 7 RC VPN client over the server’s certificate EKU field during the SSL authentication(for SSTP) and respectively IKE authentication(machine authentication for L2TP/IPsec), with one exception: the SSTP client accepts the server’s certificate if it contains no EKU field during the SSL authentication. As an extra note, remember the L2TP/IPsec VPN client’s behavior when you configure an IP address as the VPN server’s address on the client’s VPN connection.

Note: If there are multiple certificates from the same CA, it is recommended that the server’s certificate to contain within the EKU field the Server Authentication(OID: 1.3.6.1.5.5.7.3.1) + IP security IKE intermediate(OID: 1.3.6.1.5.5.8.2.2). This will ensure that this certificate from the certificates issued by the same CA will be selected by the VPN server for IKEv2 and L2TP/IPsec connections. Such a certificate can be used for SSTP(SSL authentication), IKEv2 and L2TP/IPsec VPN connections(machine(IKE) authentication)-remember the default stringent CRL check done by SSTP clients, so make sure you have the needed URL for the CRL download on this certificate(the CRL distribution point)-.

As we did here for the Windows 2003 Enterprise CA, we can have the Windows 2008 Enterprise CA to issue such a certificate, containing within the EKU field the Server Authentication(OID: 1.3.6.1.5.5.7.3.1) + IP security IKE intermediate(OID: 1.3.6.1.5.5.8.2.2), and since this certificate can be exportable, you don’t have to make the RRAS server a domain member to request such a certificate(obviously if you request this certificate from another machine, you should not do this from a PC). I won’t repeat the steps here, as they are similar to the ones I already described for the Windows 2003 Enterprise CA, instead I will put a few screen shots of such a certificate template on the Windows 2008 Enterprise CA:

To put the name and EKU checks pieces together
Say we configure an IKEv2 VPN connection on the client’s machine:

And we specify the host name of the IKEv2 VPN server on this VPN connection:

Then, for the IKEv2 VPN client from Windows 7 RC to validate the IKEv2 server’s certificate:
- this certificate has to be valid and issued by a trusted CA(this CA’s cert should be within the Trusted Root Certification Authorities the Computer Certificate Store:

- on the Subject field of the VPN server’s certificate the CN is the same with the host name we configured on our VPN connection, or if this certificate also contains a Subject Alternative Name, the DNS Name from there is the same with the host name we configured on our VPN connection(in practice, if the server’s certificate contains a SAN DNS Name entry it is probable that the DNS Name to be the same with the CN(if the CN is a host name)):

- the EKU field of the VPN server’s certificate should contain at a minimum the Server Authentication (OID: 1.3.6.1.5.5.7.3.1) entry:

As already said, the certificate from above can be used for SSTP(SSL authentication), IKEv2 and L2TP/IPsec VPN connections(machine(IKE) authentication)-remember the default stringent CRL check done by SSTP clients, so make sure you have the needed URL for the CRL download on this certificate(CRL distribution point)-.

IKEv2 Authentication Methods on Windows 7 RC
- EAP methods for user authentication: EAP-MSCHAPv2, PEAP-EAP-MSCHAPv2, EAP-TLS, PEAP-EAP-TLS(all are mutual and key derivation authentication methods). We already took a quick look at some of these authentication methods here, so I won’t discuss them again.
- machine authentication with certificates. I want to take a closer look at this authentication method, as currently it is special in a negative way.

Note: Remember that now, the IKEv2 VPN client in Windows 7 RC always, by default, validates the VPN server’s machine certificate(checking the server’s name and the EKU field on that certificate too).

Machine authentication with certificates
On the Windows 7 RC IKEv2 VPN client:

On the Windows 2008 R2 RC RRAS server, enabling machine authentication with certificates for IKEv2:

We saw above the Windows 7 IKEv2 VPN clients’ requirements for the IKEv2 VPN server’s certificate, but what kind of certificates will accept the Windows 2008 R2 RC IKEv2 VPN server from the IKEv2 VPN clients for machine authentication with certificates ?
Let’s take a look.

The results I currently obtained for the IKEv2 client’s certificate EKU field “validation”(if any) on the Windows 2008 R2 RC IKEv2 server for machine authentication with certificates:

As I did for the IKEv2 VPN server’s certificates, to quickly work with the OpenSSL CAs, I’ve modified a little bit the openssl.cfg, to contain the desired X.509 V3 extensions to be added when the CA signs the VPN client’s certificate request:

So to issue a certificate for a client, when I sign the client’s request, I specify the desired extensions to be added to the client’s certificate:

openssl req -config openssl.cfg -new -keyout keys/client1.key -out reqs/client1.csr
openssl ca -policy policy_anything -config openssl.cfg -extensions my_client_1 -cert newcerts/ca.pem -in reqs/client1.csr -keyfile keys/ca.key -out newcerts/client1.pem
openssl pkcs12 -export -in newcerts/client1.pem -inkey keys/client1.key -certfile newcerts/ca.pem -out export/client1.p12

Any EKU restrictions on the IKEv2 VPN client’s certificate in order to be accepted by the Windows Server 2003 RRAS IKEv2 VPN server ?

Not really. The bellow table presents what I’ve noticed so far:

IP security IKE intermediate =  OID: 1.3.6.1.5.5.8.2.2
Server Authentication  = OID: 1.3.6.1.5.5.7.3.1
Client Authentication  = OID: 1.3.6.1.5.5.7.3.2
Secure Email  = OID: 1.3.6.1.5.5.7.3.4
Encrypting File System =  OID: 1.3.6.1.4.1.311.10.3.4
No EKU = All Purposes EKU(sort of)

Also various SAN entries(email address, UPN, DNS Name) did not have any effect either, so I won’t discuss them.

Note: For the moment it may be a wise move to keep the option Allow machine certificate authentication for IKEv2 deselected on the Windows 2008 R2 RC RRAS server for IKEv2 VPN connections.
Why ?
Because this option appears to put too much pressure on the Trusted Root Certification Authorities the Computer Certificate Store on the Windows 2008 R2 RC server.
For example, say we’ve installed on the Windows 2008 R2 RC server a certificate from this CA(Ikev2TestCA) for IKEv2 VPN connections:

And the Trusted Root Certification Authorities the Computer Certificate Store on this Windows 2008 R2 RC RRAS server looks like this:

As can be seen the needed CA is there, but also there are other CAs. For example the My Test CA.

During my tests, I was able to establish an IKEv2 connection using machine authentication with certificates while on the client I had a valid certificate issued by a different CA than the one that issued the server’s certificate(say Ikev2TestCA), a CA which certificates was within the Trusted Root Certification Authorities the Computer Certificate Store on the Windows 2008 R2 RC RRAS server, thus a CA that the RRAS server trusts, for example My Test CA. Therefore, currently, the strength on this authentication method may be based on the “aspect” of the Trusted Root Certification Authorities the Computer Certificate Store on the Windows 2008 R2 RC RRAS server, as other layer of authentication will not take place after the machine one, and the Windows 2008 R2 RC RRAS server, for now, apparently, cannot be configured(from the GUI) to perform extra checks over the IKEv2 clients certificate(like CN or SAN field).
The current IKEv2 client from the Windows 7 RC has a similar behavior, that is, it will accept from the server a valid certificate issued by a different CA than the one that issued its certificate, if it trusts this CA(a CA which certificates was within its Trusted Root Certification Authorities the Computer Certificate Store). But the IKEv2 client from the Windows 7 RC, by default, checks the name from the server’s certificate, so even if an attacker manages to steal a valid certificate from a (web) server issued by the needed (public) CA or manages to obtain such a certificate from the needed (public) CA for apparently valid reasons, it is unlikely that this certificate will contained the needed name, so the attacker’s attempt against the Windows 7 IKEv2 client will fail.
So for the moment it may be reasonably safe to use the IKEv2 client from the Windows 7 RC with machine authentication with certificates, but on the Windows 2008 R2 RC RRAS IKEv2 VPN server if you really really want to allow machine authentication with certificates, you should keep an eye on the Trusted Root Certification Authorities the Computer Certificate Store on that server.

For example, as a comparison, for L2TP/IPsec connections, this kind of behavior does not appear to be possible: when the L2TP/IPsec “VPN client” presents a valid certificate issued by a different CA than the one that issued the server’s certificate, even if the server trusts that CA, the server will reject the “client’s” IKE credentials. The server will accept the connection if it also has a certificate from this CA within its Computer Certificate Store/Personal store, certificate that can be used for IKE authentication(and so this certificate will be used by the server for IKE authentication). The Windows 2008 R2 RC RRAS IKEv2 VPN server behaves in a similar fashion for IKEv2 connections, with that possible dangerous exception: it will accept from the IKEv2 VPN client a valid certificate issued by a different CA than the one that issued its certificate while it does not have a certificate from this different CA within its Computer Certificate Store/Personal store, it just trusts this CA(this CA’s cert was within its Trusted Root Certification Authorities the Computer Certificate Store).

CRL check
The Windows 7 RC IKEv2 VPN client or the Windows 2008 RRAS R2 RC server(for IKEv2 machine authentication with certificates) appear to be able to verify the CRL if I manually import the CRL within the Certificates Computer Store, Intermediate Certificates Authorities(the L2TP/IPsec client does not do that).
The netsh advfirewall set global ipsec strongcrlcheck with 0, 1 or 2 values seems to not have any impact or so.
It looks that by default, the Windows 7 RC IKEv2 VPN client or the Windows 2008 RRAS R2 RC server(for IKEv2 machine authentication with certificates) do not attempt to download and check the CRL.

Note: But, for example the SSTP client, by default does the CRL check, so I've published the CRL on a web site, and the SSTP client downloads it and it senses that the VPN's server certificate was revoked. Then, on the same Windows 7 RC machine, I can open without any problems an IKEv2 connection to the same VPN server, VPN server using the same revoked certificate, even if apparently, the default behavior is to have the downloaded CRL cached. If the same VPN server is used for IKEv2 and SSTP connections, with the same certificate, the default configuration in respect with CRL checking of the Windows 7 RC IKEv2 client may introduce a potential issue if a client is configured to use both, say to try IKEv2 and only fallback to SSTP if it cannot establish an IKEv2 connection, and vice-versa: to try SSTP first and fallback to IKEv2 if it cannot establish a SSTP connection. So, an attacker, that maybe somehow managed to compromise the server’s private key(and so the server’s certificate got revoked), may take advantage of this aspect, and trick the user into establishing an IKEv2 connection with him instead of the server, but this attack will fail if the EAP authentication methods are used, unless EAP-MSCHAPv2 is used and first the attacker mounts an active MITM to obtain the “data” that will allow him to mount an offline dictionary attack against the user’s credentials, and if he succeeds, he will have access to the user’s credentials. If machine authentication with certificates is used, the attacker will have the VPN client successfully connected to him instead of to the real VPN server. As said above, for SSTP connections, after the download, the CRL is cached until it may be no longer valid, I’ve managed to refresh the CRL cache using the certutil -setreg chain\ChainCacheResyncFiletime @now command(requires admin credentials). In practice, the user may attempt to use IKEv2 first, due to the mobility feature, and if it does not work then use SSTP. If SSTP and IKEv2 are used on the same RRAS server, for convenience there is a chance that the same certificate to be used for IKEv2 and SSTP connection. In that case the default stringent CRL check of the SSTP client may be pretty much useless, so the IKEv2 client should, by default, at least attempt to download the CRL and verify the server’s certificate against it, especially when there are fallback methods from protocols that perform the CRL check by default(SSTP) to ones that do not perform the CRL check(IKEv2).

Troubleshooting the new validation of the IKEv2 VPN server’s certificate
Until the admin becomes more familiar with this new validation process a few connection failures may occur.

Unfortunately for the moment, the error messages as a result of a failure to validate the server’s certificate will not provide much feedback, basically most of the time the Error 13801: IKE authentication credentials are unacceptable will appear:

Bu there is one trick, if you have some experience with SSTP, you can use the same certificate for SSL authentication on the RRAS server and attempt to connect to the server with IKEv2 and SSTP connections in parallel. SSTP error messages are more mature and provide more feedback:
- something is wrong with the server’s name, possibly you should take a closer look at the server’s certificate and the VPN server’s address from your VPN connection:

- the server’s certificate may be expired or not yet valid(I had a lab in VMware ESXi 3.5 U4, and IKEv2 connections were working fine, a fresh issued server certificate, and suddenly Error 13801 has hit me, I quickly attempted a SSTP connection from the same client machine, and I received the bellow error, looking at the client’s time I’ve notice it was a little early compared with the time of the RRAS server and of the enterprise CA, the clock somehow got desynchronized, and for this client the server’s certificate was not yet valid):

- the CA that has issued the server’s certificate is not trusted(don’t forget to add the CA’s certificate into the Trusted Root Certification Authorities the Computer Certificate Store):

Additionally you can use the Netsh Commands for Windows Filtering Platform in Windows Server 2008 R2 to troubleshoot IKEv2 connection errors, for example the netsh wfp capture start begins a WFP diagnostics capture session, you can start such a session, repro the problem and then stop the capture session with netsh wfp capture stop. If so you will end up with a .cab file containing a .xml and a .etl output files. Currently, as said in that Microsoft doc, the .etl file “is not directly usable by an administrator” and “it can be provided to Microsoft Customer Support Services if requested”(this kinda sux if you ask me).

A possible issue on the VPN client or CMAK profiles on Windows 7 RC  - Weakening the protection afforded for the communication channel “with” the default tunnel strategy behavior
As described here, VPN tunnel strategy - defining the connection order between various tunnel types, you can:
- configure the Windows 7 RC VPN client to Automatic for the type of VPN, which means: try IKEv2 first, if that fails try SSTP next, if that also fails try PPTP next and if that fails too, try L2TP/IPsec last. If L2TP/IPsec fails, then stop the connection establishment and log an error.

- define the tunnel strategy using a CMAK profile, for example Try IKEv2 first: try IKEv2 first, if that fails try SSTP next, if that also fails try PPTP next and if that fails too, try L2TP/IPsec last. If L2TP/IPsec fails, then stop the connection establishment and log an error. For CMAK profiles for Windows 7 RC, as currently writing, according to this Microsoft document related to CMAK on Windows Server 2008 R2 RC called Networking Keys, this behavior is part from VpnStrategy3, see the [Networking&TunnelDUN] section.
 

From a practical point of view this is great, easy to use and may be appealing: try IKEv2 first to benefit from the mobility feature, but if that fails due to connectivity issues(ports blocked, behind proxy) then try SSTP, which may work, as that was SSTP designed for, to solve the connectivity issues.
But the problem is that, by default, the tries do not stop here: try IKEv2 first, if that fails try SSTP next, if that also fails stop.
And the issue that may appear from this problem is that an attacker may try weakening the protection afforded for the communication channel. While the protocols themselves, IKEv2 or SSTP may not allow that(say weakening the cipher suites), the default tunnel strategy behavior of the VPN client or CMAK profile allow that. Because after it has tried the first two, IKEv2 and SSTP, the VPN client will not stop, it will try the weak PPTP(there may be little point in trying L2TP/IPsec since IKEv2 failed, and for connectivity they have the same requirements(UDP port 500 and ESP or UDP port 4500), - L2TP/IPsec will work only if a pre-shared key was specified or a computer certificates exist on the client-).
Imagine that the VPN client connects from an anonymous wireless LAN(say a hotel). An attacker uses a rogue AP and so the client is connected to him and not to the intended AP. The attacker blocks IKEv2, blocks SSTP and lets through PPTP, thus the client will end up using a weak VPN protocol. Even further, if EAP-MSCHAPv2 is used for user authentication, in this case IKEv2 and SSTP protects the user’s credentials against offline dictionary attacks, however PPTP with EAP-MSCHAPv2 will not offer this protection. For that you will have to use PEAP-EAP-MSCHAPv2(and the option Do not prompt user to authorize new servers or trusted certification authorities should be selected). If you use NAP, you will use PEAP by default(see NAP’s requirements), so the users credentials, depending on how validation for PEAP server’s certificate was configured on the client, may be protected.

Is the connectivity need so stringent that this need will allow weakening the protection afforded for the communication channel at such extent(using PPTP) ?
Anyway, if SSTP does not work, it is highly likely that PPTP will not have any chance to work.

So right now, perhaps it should be advisable to define two VPN connections or two CMAK profiles, one using only IKEv2 and the other only SSTP, and so the VPN user will use them as needed.

Default VPN connection and default CMAK profile settings for the Automatic option on the VPN connection, respectively for the Try IKEv2 First on the CMAK profile(created on Windows Server 2008 R2 RC):

To end this blog entry, I would say it would be interesting to see if Microsoft will expose in Windows 7 and Windows 2008 R2 the default cipher suites used for IKEv2 and IPsec for VPN Reconnect or for IKEv1 and IPsec for L2TP/IPsec, making them customizable(maybe one wants to allow only AES, ECC cryptography and the SHA2 family), or it will just continue the hide and seek game, game which for Windows Server 2003 and Windows XP SP3 resulted that in year 2009, Diffie-Hellman MODP Group 1 and DES are still allowed by default for L2TP/IPsec connections. Way to go Microsoft!  –:(.