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

[semalb]

I've been struggling with the deployment of an IKEv2 VPN using Radius authentication (which in turn uses EAP-TLS to authenticate clients) for weeks before being successfully able to solve every issue.
I'm sharing my experiences here so that you can avoid the headaches I've gone though.
It will be a long thread, I'll update this post with the other parts when they're ready.
I'm a little slow, sadly, because English is not my primary language.

Preface:

• Windows 10 (any version) does not support fragmentation at the IKEv2 level. This means you need to keep your PKI infrastructure and certificate size as simple as possible. I had to use ECDSA with a single CA to avoid any fragments. I tried first to authenticate clients using an intermediate ECDSA CA but the client was sending the entire chain and fragmentation occurred.

• Split Tunneling:

  • The desktop version of windows 10 1607 requires to enable split tunnelling and add a route via powershell to correctly route all VPN traffic through the tunnel and use the mobile data connection for internet surfing. You have two options here. Either you allow your IPSec mobile client to access internet through pfsense or you enable split tunnelling:
    Set-vpnconnection -name "VPN-NAME" -splittunneling $true
    Add-VpnConnectionRoute -Name "VPN-NAME" -DestinationPrefix networkid/maskbits

  • The mobile version of Windows 10 1607 works differently. If you set the connection to Automatic, split tunneling is enabled by default and routes are correctly learned. Thanks Microsoft for not documenting it.

• I don't know if you ever heard of Windows Image and Configuration Designer, which is supposed to create packages for configuring windows 10 (any version). Well, it works like a charm for everything BUT for VPN profiles and documentation is scarce. So I'd rely to this only for certificate distribution and WPA2-Enterpise profile. I opened up a post on technet about this, but the only reply I got was (as always) clumsy and useless. If anyone of you ever tried it and managed to successfully provision a VPN connection, I'd be really glad to hear how you did that.

EDIT: With Windows 10 1703 it's finally possible to use windows ICD to configure the VPN with some custom modifications to the package. This allows us to define routes for the split tunnel configuration, dns for the vpn, cypher transforms and many other settings in a single file, and deploy everything in a single package.

Part one: WPA2-Enterprise with Radius and EAP-TLS
Settings RADIUS on Pfsense:

• Create a Root CA with an ECDSA key. You can't use pfsense certificate manager for ECDSA certificates. You can use OpenSSL command line to do that, or you can use any other software. I started with OpenSSL but then I had to switch to a GUI software (XCA) because I had to create an enormous quantity of certificates to find the best size. I used the secp384r1 curve for all certificates, CA, server and client. My CA has a ecdsa-with-SHA384 sig and and my certificates a ecdsa-with-SHA256 signature.

• Create the Pfsense Server certificate. Be sure to add the 1.3.6.1.5.5.8.2.2 (ike intermediate) and the 1.3.6.1.5.5.7.3.1 (server auth) Extended Key Usage to the certificate and all the required SAN names since you will use this certificate for the Webconfigurator, for the Radius Server, and for the IPSec listener.

• Create the certificates for your clients, using Digital signature, key encipherment and data encipherment as key usage. As a common name, I used the email, this way I can match them with the usernames in freeradius.

• Generate the CA crl. Freeradius needs a CRL to validate client certificates.

• Import the CA certificate (without the key) the firewall certificate (with the key) and the CRL in the certificate manager.

• Install freeradius and configure the eap part:

  • Disable weak EAP Types: true.

  • Default EAP Type: TLS

  • EAP-TLS Section:

    • Use Pfsense Certificate manager: true.

    • SSL CA Cert: Your root CA.

    • SSL Revocation list: your CRL.

    • Optional: validate the Client Certificate Common Name.

    • Leave the rest as default.

  • In NAS / Clients configure your AP Address and your pfsense address with long shared secrets for better security.

  • In Users configure your users. If you use freeradius also for logins on network devices configure the Reply-Item accordingly. For cisco devices it's "Service-Type == 7"

• In System -> User Manager -> Authentication server, configure pfsense to use itself as a Radius authentication server (required for IPSec).

• Configure your AP to use a radius server by setting the Pfsense IP and the shared secret you generated earlier, and configure your SSID to use WPA2-Enteprise with EAP-AES. I can't really post a guide here, because every AP has its own interface or commands, I used a cisco aironet and I can eventually post a configuration sample if you need it.

• Test WPA2-Enterpise configuration. This also allows us to test the correct configuration of radius authentication using EAP-TLS.

You should have now a working WPA2-Enterprise setup for your wireless using EAP-RADIUS with TLS authentication.

[semalb]

Test WPA2-Enterprise
Configure Windows 10 to test WPA2-Enterprise, the manual way:

1. In a PC with a wireless interface, import the CA certificate (without the key) under the Trusted Root Certification Authorities node.
a. Execute mmc.exe with local admin privileges.
b. File -> add/remove snap-in -> certificates -> Add -> computer account -> local computer ->ok.
c. Navigate under Trusted Root Certification Authorities -> certicficates.
d. Right Click -> All tasks -> import.
e. Choose the CA certificate (again, without the key) and import it.
2. Import the user certificate in the personal storage of the user:
a. Open mmc in the user context.
b. File -> add/remove snap-in -> certificates -> Add -> Current User -> ok.
c. Import the P12 certificate under personal. It will ask you the password for the private key. If the import is successful, you'll see a little key near the certificate icon meaning you also have the private key corresponding to the certificate.
3. Open network and sharing center and click setup a new connection
4. Chose manually connect to a wireless network
5. Put your WPA2-Ent SSID name under network name, and unser security type set WPA2-Enterprise.
6. Hit next. Then click on change connection settings.
7. Under the security tab, select Smart card or other certificate under Chose a network authentication method, then click settings right next to it.
8. Select User a certificate on this computer, then advanced.
9. Flag Certificate issuer and chose your CA as certificate issuer. Don't tamper with the EKU settings unless you have advanced requirements.
10. Click OK.
11. Under trusted root certification authorities in the previous window flag your RootCA. Leave everything else as default unless you have stricter requirements.
12. Click ok twice then close the Manually Connect to a wireless network window.
13. You should successfully be able to connect to the wireless SSID with WPA2-Enterprise.

If anything goes wrong here, it's between the AP and the radius server, or in the radius server configuration. You can troubleshoot this under status ->system logs ->System/general in pfsense.

I'm now writing the IKEv2 part and will post it soon.

[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.