Setup:

Server 2012 with the DirectAccess and VPN (RAS) Role installed.

We have our own PKI, CRL and AIA is available over the Internet.

The DA Server is behind a NAT device and has 2 Interfaces (1 facing LAN, 1 facing the DMZ).

We have Firewall Rules allowing 443/tcp, 500/udp, 4500/udp and IP Protocol 50 (ESP) to the DMZ Interface of the DA Server.

Status:

DA is working as expected, SSTP too. We disabled all PPTP Interfaces in the Routing and RAS console (its not allowed in the Firewall anyway, but you never know) and to allow various Mobile Devices to dial in, we entered a Pre-shared Key in the Routing and RAS Console to allow the Custom Policy for L2TP/IKEv2 connections. Apart from that, the DA setup should be pretty standard.

While testing the VPN connections and possibilities with Windows 7 and Windows 8 systems, we were able to use SSTP and L2TP/IPSec. But IKEv2 did not work. Since it utilizes the same Firewall Ports and Protocols as L2TP/IPSec (according this post), I wondered if my certificate is the problem. So I started BPA and it complained, that the Certificate utilized by IKEv2 should contain the IP address or the Host name of the external Interface of the DA Server.

I found this in Technet and tried to follow its advise, but I struggle with step 5 a bit. I also found a RFC about IKEv2 and Certificates (unfortunately I cannot find the link anymore), but it was mentioned, that the Subject Name should be empty and all information should be stored in the SAN. So I tried IKEv2 with different certificates, but whatever I do I either break DA (the Remote Access Setup is not accepting Certificates with an empty Subject Name) or SSTP stops working (I tried to enter the IP in the Certificates SubjectName once).

Our current DA Certificate has filled out CN (external DNS Name of the DA Server), OU, O, L, S, C and contains the external DNS Name in the SANs DNS= field. This works fine for DA, SSTP and L2TP/IPSec, but not for IKEv2.

I already tried to add the optional "IKE intermediate purpose" as mentioned in the article, but it did not change anything for me for IKEv2 connectivity.

Point 5 in the Technet article mentiones that you can either put in the public IP or the DNS name as a regular expression. I wonder how that RegEx entry would look like. It also does not mention any of the other Subject fields I filled out. Should they be empty? What about the SAN? I can enter DNS and IPv4 addresses here. There are so many combinations that it may take a while for me to find the right combination to create a Certificate which serves all purposes.

As far as I understood I should not tinker with the certificate settings in the Routing and RAS Console, but everything should be configured in the Remote Access Management Console. But there are not many options for SSTP, IKEv2 or L2TP/IPSec you can choose from. Its more a matter of turning VPN on or off there. How exactly should a certificate be created to be able to use all possibilities?

We found out that not the Certificate was the problem.

We activated "Allow custom IPSec Policy" in the RRAS settings to enter a Shared Secret to make it possible for some Mobile devices to connect via L2TP/IPSec. If you do this, Windows 7 and 8 do not seem to be able to connect via IKEv2 anymore, because you cannot enter a preshared Key in the Dialin Settings in Windows. To make matters worse, it made the whole RAS stuff in Windows to completely cease function until you make a reboot (we tested on multiple PCs with Windows 7 and 8).

So other than what the option implies to me as a non-native speaker is not allowing a custom IPSec Policy, but enforcing it instead.

To solve this matter and to still alow our Mobile devices to use L2TP/IPSec with the preshared Key, we just disabled all the IKEv2 Adapters in the RRAS services.

• Marked as answer by René Büdinger Wednesday, May 29, 2013 10:52 AM

We found out that not the Certificate was the problem.

We activated "Allow custom IPSec Policy" in the RRAS settings to enter a Shared Secret to make it possible for some Mobile devices to connect via L2TP/IPSec. If you do this, Windows 7 and 8 do not seem to be able to connect via IKEv2 anymore, because you cannot enter a preshared Key in the Dialin Settings in Windows. To make matters worse, it made the whole RAS stuff in Windows to completely cease function until you make a reboot (we tested on multiple PCs with Windows 7 and 8).

So other than what the option implies to me as a non-native speaker is not allowing a custom IPSec Policy, but enforcing it instead.

To solve this matter and to still alow our Mobile devices to use L2TP/IPSec with the preshared Key, we just disabled all the IKEv2 Adapters in the RRAS services.

• Marked as answer by René Büdinger Wednesday, May 29, 2013 10:52 AM

Hello,

I am facing pretty same problem regarding IKEv2 in server 2012 can you please briefly tell me how did you resolve your problem...????

Thanks...