IKEv2 and WPA2-Enterprise with EAP-RADIUS on Win10 1607\. Finally working!

[semalb]

Part 2: Setting up an IKEv2 VPN with ECDSA Certificates.

Now that we have our radius server in place and that it successfully authenticate users using EAP-TLS we can proceed to set up our IKEv2 VPN.

First things first, Pfsense webgui doesn’t really like ECDSA keys yet. It keeps writing the key as RSA under /var/etc/ipsec/ipsec.secrets everytime we start the service, leading to a "private key not found" message when we try to connect. To fix this, we need to open and modify a line of code under /etc/inc/vpn.inc. They'll probably fix this in later versions of pfsense.
Please note, I've tested it for a few days and it seems to work perfectly, but ALL your IPSEC endpoints in pfsense MUST now use ECSDA Server certificates. I know this might not be an optimal solution for some of you, in this case wait for a REAL fix. This is just a workaround to be able to connect using the Windows 10 native ikev2 provider AND avoid fragmentation at the IP level.

–-------------------- WORKAROUND ----------------------
Save a copy of vpn.inc for rollback:
Go to diagnostics -> Command prompt and under execute shell command write

cp /etc/inc/vpn.inc /etc/inc/vpn.inc.old

And execute it.

Go to diagnostics -> edit file and browse to /etc/inc/. Check you have the vpn.inc.old file just created earlier.
Then open vpn.inc. Search for this lines, approximately in the middle of the file (line 723 for me)

$pskconf .= " : RSA {$ph1keyfile}\n";

And change it to

$pskconf .= " : ECDSA {$ph1keyfile}\n";

This is enough to use ECDSA certs for IKEv2 until the GUI supports it.
–----------------------------------------------------------------

Now go to VPN -> ikev2.
1. Select Mobile Client.
a. Enable IPSec Mobile Client Support: True
b. User Authentication: you should have two options now, if you set up the authentication server in user manager. Chose the Freeradius connection.
c. chose a virtual IP address pool
d. Provide a list to accessible networks to the clients: true
e. Configure the rest of the settings accordingly but remember we can override them with the package deployment later.
2. Go back to tunnels and configure the P1 part:
a. As phase 1 proposal select EAP-Radius as authentication method.
b. My Identifier: distinguished name, then set the name of the server as in the certificate.
c. Peer identifier: any (this is the only one that worked for me).
d. My certificate: the same SSL certificate for radius and webGUI.
e. Encryption: I used AES-CBC-256 with SHA265, DH 2 (we're gonna change them later)
f. Enable MOBIKE and leave everything else as default.
3. Phase 2, change the values accordingly:
a. Encryption Algorithms: AES256
b. Hash Algorithms: SHA256
c. PFS Key Group: none. (we're gonna change them later)

Done. This should be enough to avoid fragments, since ecdsa certificates have much smaller size than standard ones. In the next post we're gonna test the connection with a pc and verify no fragmentation occurs. We will use a pc to avoid importing multiple personal certificates on the WM10 phone (since they cannot be removed later).

[semalb]

Test VPN:
This is one of the most tedious part. It required me days to find the right certificate size and chain to avoid fragments in the connection.
We can use the previous PC where we tested WPA2-Enterprise since we have already all certs in place.

1. At the command prompt (as user) execute rasphone.exe
2. Create a new connection, type Workplace Network
3. Insert the address and the connection name, then create.
4. Now chose the newly created connection, and click properties.
5. On security, leave Automatic as type of vpn (the first connection it tries is IKEv2 so there's no delay)
6. Data encryption: require encryption
7. Use Extensible Authentication Protocol (EAP): Smartcard or other certificate.
8. Configure the properties as for the WPA2-Enterprise. Remember to select the right CA for the server certificate and the CA (the same for me) for the client authentication. Again, don't mess with the EKUs unless you requirements are stricter.
9. Click ok twice to save all settings then exit.
10. Test that the vpn connects successfully. Use a cable or a WLAN to test this, which is likely to pass fragments. If authentication is successful disconnect and proceed with the packet capture.
11. Fragmentation check:
a. On pfsense go to diagnostic -> packet capture.
b. Select the public interface of your firewall, and as host address type the public ip of your test PC.
c. Run the packet catpure.
d. Try the VPN
e. Stop the capture download it, and open it with whiteshark.
f. Check that NO fragmentation occurs at the IP level. The capture should be like in the first attachment. A second attachment shows fragmentation.
12. If it works, and there's no fragmentation, it's over. You have a perfectly functioning ikev2 vpn that works on windows 10 and its mobile counterpart.

Import all certificates into windows mobile and setup the vpn using "Automatic" so that it learns the routes correctly and enables split tunelling.
If you need better cypher suites or at least better DH (MODP1024 is a little weak nowadays) and PFS you'll need to keep reading as we're going to create a ppkg to install on our windows 10 devices to unlock better crypto transforms.

Extracting the EAP Blob from the VPN connection:
First thing we need from our newly working VPN connection, is to extract the EAP blob for automatic certificate filtering. This allows to setup both the wireless and vpn connection without user intervention.
Open powershell and run:

• Get-vpnconnection | fl name. Note the name of the our test vpn connection

• $vpn = get-vpnconnection -name "VPN Name"

• $vpn.EapConfigXmlStream.InnerXml > eapstream.xml

In the next post we'll create the ppkg file to configure both the VPN and the WPA2-Ent Wireless settings.
It will take a little more time to write the next part since i'm trying to take some screenshots and post them here.

[semalb]

This part is for those who don't have an MDM infrastructure in place. If you have a Mobile Device Management infrastructure, you should be able to import the OMA DM device descriptor and use it for pushing your profile directly from the software.

In this post we'll create a package to install the required certificates (read Root CA cert), the WPA2 profile for wireless.
Again, probably not everyone knows Windows ICD. It's a package builder part of windows ADK for provisioning windows settings in a BYOD environment. This is the only standalone tool i've found so far to create provisioning packages and there's almost no documentation (well, at least real useful documentation) around. Moreover, the whole provisioning framework lacks of basic debugging features to really understand what's going on under the hood, this makes troubleshooting of failed installations a real pain.

You can download the latest version of windows ADK (be sure to use the same release of your target windows clients) here

You can download the Right XML Profile for your WPA or WPA2-Enterprise Wifi here

Create the XML for Wifi profile:
Download the right xml profile for your WPA connection from the url, paste it on any text editor and replace the whole <eapconfig></eapconfig>part with the one in your EAPstream.xml created earlier from powershell (post above).
There are two names in this xml. The first one is the name of the connection, right after the WLANProfile node. It's just a name for the profile, but really isn't important. Then there's the name under the SSID node, which must match the name of your wireless SSID. I'd suggest to use the same name in both fields to avoid any confusion.

Save the modified xml file.

Create the package for the WiFi Profile:
Fire up windows ICD.
Create a new "Advanced Provisioning" (pic 1) project, Give it a name and a description (pic 2) then chose "All Windows Mobile Editions" (pic 3) to filter out ALL non compatible settings with windows mobile.
You'll end up with a tree of runtime settings to choose from. (pic 4)
We need the certificates/RootCertificates node and the ConnectivityProfile/WLAN/Profiles node.
Configure the RootCertificates with a new certificate name (use what you want) and its path. (pic 5)
Then move to the ConnectivityProfile/WLAN/Profiles node click browse and select your WPA Profile xml. Then hit add. It will create the new profile automatically. (pic 6)

Save the project and build the package using Export -> provisioningpackage.
Select Owner: IT Admin and leave the rest as it is.
Don't sign nor encrypt package and keep hitting next until you have the BUILD option.
Try the package in a windows 10 PC with a Wireless card (otherwise it fails) by just double clicking it. It should install without any error. Check under Settings (new metro menu or whatever it's called) -> Accounts -> Access work or school -> add or remove a provisioning package. It should appear there with date and time of installation. If there's any error it will say the installation has failed. (pic 7)
Immediately when you are in range of your Wireless Connection, it should connect. If it doesn't you forgot to add the user certificate with the private key to the personal store of the user you're currently signed in or you made a mistake in the xml file.

The important part here is that IT HAS to install correctly, and if it doesn't it means there's something wrong in the package that prevents its installation, and the pain begins. I might help with some troubleshooting but since there's almost no debug tools or logs you can send me, we're really blind here. :(

In the next, and hopefully last part we'll create a second package for the VPN. Since it's something we must manually edit it's better to split it from the other configuration packages. This allows us to track down what part of the provisioning settings are broken.


[semalb]

Creating the VPN package: (this part requires Windows 10 Creators Update 1703)
The whole provisioning system in Windows 10 uses Configuration Service Providers (CSP) to configure different part of the OS through packages or MDM softwares.
While in previous version of windows 10 the VPNv2 CSP was broken and was never called to set up VPN settings, newest versions (1703, Creators Update) seems to respond very well when using the ProfileXML feature.

More technical details about the VPNv2 CSP can be found here, but all you need to know is we can create an xml formatted profile to insert into a windows package and configure the VPN automatically as you want to, with routes, split tunnels, certificates filtering and (most important) cypher transforms.
The only problem is that windows ICD doesn't support profilexml files for VPN, although it does for WiFi. Well, fortunately we can modify the package itself and create our own support without too much hassle. It seems windows doesn't care about signatures in the catalog file, so we're good to go.
I tested it on my surface pro with 1703 15063.13 and it played nice.

Note:
It literally took me WEEKS to understand how packages work and again days to understand how to change the packages to support the VPN ProfileXML file. There's literally NO information on technet, no blogs and almost no useful debug tools, so you're just blind here if something doesn't work. So really double check EVERYTHING. Even a typo can screw up the entire process, and finding it is really time expensive.

So first, let's create a NEW dummy package with windows ICD for a VPN. Proceed as before for the WiFi package but instead of the certificates and the wifi profile, just configure a dummy VPN profile with enough settings to create the package, and build it. Don't really care about the settings, we're gonna open the package later with 7zip and modify the runtime script with what we want. We just need the package to be built for the vpn.

Then we need to create our own ProfileXML. This is the one I used for my connection.
Refer to the VPNv2 CSP link for explanation of all the different parts. I derived this profile from here. You'll also find the schema for validation if you want it.

<vpnprofile>  
  <nativeprofile><servers>servername.domain.com</servers>  
    <nativeprotocoltype>IKEv2</nativeprotocoltype>  
    <authentication><usermethod>Eap</usermethod>  
      <machinemethod>Eap</machinemethod>  
      <eap><configuration><eaphostconfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig">EAP XML BLOB</eaphostconfig></configuration></eap></authentication>   
    <routingpolicytype>SplitTunnel</routingpolicytype>  
    <disableclassbaseddefaultroute>true</disableclassbaseddefaultroute>  
	 <cryptographysuite><encryptionmethod>AES256</encryptionmethod>
		<integritycheckmethod>SHA384</integritycheckmethod>
		<dhgroup>ECP384</dhgroup>
		<ciphertransformconstants>AES256</ciphertransformconstants>
		<authenticationtransformconstants>SHA256128</authenticationtransformconstants>
		<pfsgroup>ECP384</pfsgroup></cryptographysuite></nativeprofile> 
  <remembercredentials>true</remembercredentials>  
  <alwayson>true</alwayson>  
  <route><address>192.168.0.0</address>

    <prefixsize>24</prefixsize></route> 
  <trustednetworkdetection>Your internal domain name, or WiFi SSID name</trustednetworkdetection> 
  <domainnameinformation><domainname>Your internal domain name</domainname>  
    <dnsservers>your internal dns server</dnsservers></domainnameinformation>   
  <dnssuffix>internal dns suffix</dnssuffix>  
</vpnprofile> 

Remember the EAP blob we created earlier in powershell? We're using it in place of the <eaphostconfig>in the profileXML file for certificate filtering, like we did earlier for the WPA2 profile.
Once the file is ready, remove all tabs, and all CRLF and double spaces, then convert all needed character with the escapes for HTML. You can do everything in notepad++ or here.

Open the ppkg created earlier with 7zip.
Go to Multivariant\0\Prov\Runtime\0__ConnectivityProfiles_nameofyourpackage_nameofyourvpnprofile.provxml, open it and have a look at it. We'll need to use the ./Device/Vendor/MSFT/VPNv2/ProfileName/ProfileXML node path.
So we're going to wipe everything out, and change it with something like this:

 <wap-provisioningdoc><characteristic type="VPNv2" scope="Device"><characteristic type="nameofyourVPNprofile"><parm name="ProfileXML" value="paste-your-escaped-text-here" datatype="string"></parm></characteristic></characteristic></wap-provisioningdoc> 

Change the name under nameofyourVPNprofile to match your VPN name and paste ALL the escaped profilexml text as value of the parm name Profilexml.
Save the file directly inside the ppkg file with 7zip.

Now, get back to the IKEv2 settings on pfsense and change P1 DH group to 20 (nist ECP384), and P2 PFS to 20 (nist ECP384). I used these settings for my VPN and it works. AES-GCM won't work out of the box with windows yet, because it requires modifying the ipsec policies, thus breaking compatibility with Windows Mobile. I'm working on this, maybe we can do that through another package.

Try the package on a Windows 10 1703 by double clicking it. It should install without any hassle. You should now be able to connect to an IKEv2 vpn with definitely better crypto transforms than windows defaults. Have fun playing with the transforms and find your sweet spot.

NB: I didn't try this on Windows Mobile 10 1703 because the Creator update hasn't been released to the Release Preview Ring yet. If someone wants to try and share the results, I'd be glad. Otherwise, I'll post my experience with windows 10 mobile as soon as they move the Release preview ring to CU. I'm confident though, this release is the right one for the VPNv2 CSP to work with provisioning packages.

Well that's it. I hope you'll find it useful.
Let me know if it worked out for you too.</eaphostconfig>

[semalb]

FYI, I installed the latest build of windows mobile 10 CU (10.0.15063.138) available on Slow Ring, and the VPN package created earlier worked perfectly.
There's still a problem with the TrustedNetworkDecetion part that does not detect and stop VPN when you're inside the corporate network, but everything else works like a charm!

If I manage to fix it, i'll post it here.

[maxdevaine]

You are amazing !!!

I tried this on Windows Mobile 1703 and it works. On Windows 10 1709 this works too.
I make only one change, I removed section with "CryptographySuite" because at this time I not using elyptic cyphers.

You saved my life, man.

Thank you very much.

Max
PS: I don't using pfSense, I using strongswan on debian stretch. Now I have working solution for all clients (Windows 7, 8.1, 10, Windows Mobile 8.1, 10, Android, iPhone 11, Linux) , on All clients I using split connection (only specific communication is via VPN, other communication is directly to internet)

[TMA-3]

@semalb:

First things first, Pfsense webgui doesn’t really like ECDSA keys yet. It keeps writing the key as RSA under /var/etc/ipsec/ipsec.secrets everytime we start the service, leading to a "private key not found" message when we try to connect. To fix this, we need to open and modify a line of code under /etc/inc/vpn.inc. They'll probably fix this in later versions of pfsense.
Please note, I've tested it for a few days and it seems to work perfectly, but ALL your IPSEC endpoints in pfsense MUST now use ECSDA Server certificates. I know this might not be an optimal solution for some of you, in this case wait for a REAL fix. This is just a workaround to be able to connect using the Windows 10 native ikev2 provider AND avoid fragmentation at the IP level.

The information in your posts regarding fragmentation is very much appreciated!  I spent a lot of time getting our PKI set up and pfSense configured.  I tested, verified, tweaked, tested, tested some more and thought I had it nailed.  I took my pfSense box to the data center, installed it and tested again - everything worked.  I got home and tested again and couldn't connect - Windows reported error 809!  I saw mention of some registry settings one can add, but nothing helped.  Using ECDSA was the key - thank you.  I'm curious - is this a Microsoft problem or a pfSense problem?  Both?

I'm a little concerned that I've created an installation that will break at the next upgrade, but I hope ECDSA support will be added soon so I don't have to worry.

Thanks again for sharing all this information - it is invaluable!

[ltctech]

It appears that the latest version of pfSense 2.4.2 and Windows 10 1709 has no problem with IKEv2 fragmentation.

However, Broadcom network cards have an issue with reassembling fragmented UDP packets when hardware checksum offloading is enabled. Windows tends to send all of the CAs it knows about to the IKEv2 server during authentication. This may push the authentication packet beyond 1500 bytes requiring fragmentation. If the IKEv2 server is running on a Broadcom network card it will fail to reassemble the authentication packet (bad checksum) and will timeout. To avoid this issue one should tick "Disable hardware checksum offload" in System -> Advanced -> Networking.

This checksum offload issue seems to affect Broadcom "bge" cards. Intel "em" cards appear to be immune.

To quickly check for a UDP fragment reassembly issue perform a large DNS request from pfSense's ssh console:

dig -x 17.178.96.7

If you get a timeout and the server is still up then you have an issue. If everything is OK the bottom should read something like:

;; Query time: 23 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Mar 15 16:40:22 PDT 2018
;; MSG SIZE  rcvd: 3705

Note that the "MSG SIZE" is bigger than 1500. If it's any less than 1500 it will not result in fragmentation and it's not testing reassembly.

This appears to be a known issue with "bge" going back to 2007:
https://lists.freebsd.org/pipermail/freebsd-pf/2007-June/003530.html

Windows CA fragmentation issue explained:
https://wiki.strongswan.org/issues/965#note-1

[semalb]

@ltctech:

It appears that the latest version of pfSense 2.4.2 and Windows 10 1709 has no problem with IKEv2 fragmentation.

However, Broadcom network cards have an issue with reassembling fragmented UDP packets when hardware checksum offloading is enabled. Windows tends to send all of the CAs it knows about to the IKEv2 server during authentication. This may push the authentication packet beyond 1500 bytes requiring fragmentation. If the IKEv2 server is running on a Broadcom network card it will fail to reassemble the authentication packet (bad checksum) and will timeout. To avoid this issue one should tick "Disable hardware checksum offload" in System -> Advanced -> Networking.

This checksum offload issue seems to affect Broadcom "bge" cards. Intel "em" cards appear to be immune.

To quickly check for a UDP fragment reassembly issue perform a large DNS request from pfSense's ssh console:

dig -x 17.178.96.7

If you get a timeout and the server is still up then you have an issue. If everything is OK the bottom should read something like:

;; Query time: 23 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Mar 15 16:40:22 PDT 2018
;; MSG SIZE  rcvd: 3705

Note that the "MSG SIZE" is bigger than 1500. If it's any less than 1500 it will not result in fragmentation and it's not testing reassembly.

This appears to be a known issue with "bge" going back to 2007:
https://lists.freebsd.org/pipermail/freebsd-pf/2007-June/003530.html

Windows CA fragmentation issue explained:
https://wiki.strongswan.org/issues/965#note-1

thank you ltctech, i'm gonna read this during the weekend and try the new stuffs.
Unfortunately I still use windows mobile which is stuck to 1703 so there won't be any fun for me regarding fragmentation

[semalb]

@TMA-3:

I'm curious - is this a Microsoft problem or a pfSense problem?  Both?

I'm a little concerned that I've created an installation that will break at the next upgrade, but I hope ECDSA support will be added soon so I don't have to worry.

Thanks again for sharing all this information - it is invaluable!

Sorry I haven't replied soon, I had some issues in the last months and I had very little time to connect to anything. I'm pretty sure it's a microsoft issue and specific with IKEv2. IKEv1 works perfectly with fragments. Probably (and hopefully) next versions will fix it.

FYI, it's very possible to fix the ECDSA even on latest version. I tested it this week. I'll update this post soon using public certificates from letsencrypt.