When configuring StrongSwan IKEv2 VPN between Linux servers and Windows 10 clients, the "policy match error" (Event ID 13868) typically indicates a mismatch in IPsec/IKE configuration parameters. Windows is particularly strict about these parameters, often rejecting connections when proposals don't exactly match.

The main culprits are usually:

• Incompatible IKE proposals
• Mismatched authentication methods
• DH group inconsistencies
• Incorrect lifetime values
• Missing or incorrect virtual IP pools

First, verify your StrongSwan configuration. A working example for Windows 10 compatibility would look like:

# /etc/ipsec.conf
conn ikev2-vpn
    auto=add
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes
    ike=aes256-sha256-modp2048,aes128-sha1-modp2048!
    esp=aes256-sha256,aes128-sha1!
    dpdaction=clear
    dpddelay=300s
    rekey=no
    left=%any
    leftid=@vpn.example.com
    leftcert=server-cert.pem
    leftsendcert=always
    leftsubnet=0.0.0.0/0
    right=%any
    rightid=%any
    rightauth=eap-mschapv2
    rightsourceip=10.10.10.0/24
    rightsendcert=never
    eap_identity=%identity

For Windows clients, you might need to modify registry settings to match server configurations:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters]
"NegotiateDH2048_AES256"=dword:00000001
"AssumeUDPEncapsulationContextOnSendRule"=dword:00000002

Windows 10 has specific certificate requirements for IKEv2:

• Server certificate must contain Server Authentication EKU (1.3.6.1.5.5.7.3.1)
• CN or SAN must match the server's FQDN
• Key length ≥ 2048 bits
• SHA-256 signature algorithm

Use Wireshark to capture IKEv2 negotiations. Filter with udp.port == 500 || udp.port == 4500 and look for NOTIFY messages indicating policy mismatches.

If native Windows VPN fails, consider using the StrongSwan Windows client with modified config:

# strongswan.conf
charon {
    load_modular = yes
    plugins {
        include strongswan.d/charon/*.conf
    }
    filelog {
        /var/log/strongswan.charon.log {
            time_format = %b %e %T
            ike_name = yes
            append = no
            default = 2
            flush_line = yes
        }
    }
}

The "Policy Match Error" (Event ID 13868) occurs when Windows 10's built-in VPN client fails to establish a connection with your StrongSwan IKEv2 server due to mismatched security policies. This typically happens when the client and server can't agree on encryption algorithms, authentication methods, or other security parameters.

First, verify your StrongSwan configuration on Ubuntu. The most common issue is missing or mismatched IKE and ESP proposals. Here's a working ipsec.conf example:

config setup
    charondebug="ike 2, cfg 2"
    uniqueids=no

conn ikev2-vpn
    auto=add
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes
    ike=aes256-sha256-modp2048!
    esp=aes256-sha256!
    dpdaction=clear
    dpddelay=300s
    rekey=no
    left=%any
    leftid=@yourvpn.domain.com
    leftcert=server-cert.pem
    leftsendcert=always
    leftsubnet=0.0.0.0/0
    right=%any
    rightid=%any
    rightauth=eap-mschapv2
    rightsourceip=10.10.10.0/24
    rightdns=8.8.8.8,8.8.4.4
    rightsendcert=never
    eap_identity=%identity

Windows 10 has specific requirements for IKEv2 connections. Create a PowerShell script to configure the VPN connection properly:

# Create VPN connection
Add-VpnConnection -Name "StrongSwan VPN" 
    -ServerAddress "your.vpn.server" 
    -TunnelType IKEv2 
    -EncryptionLevel Required 
    -AuthenticationMethod EAP 
    -RememberCredential $true

# Set VPN connection properties
Set-VpnConnection -Name "StrongSwan VPN" 
    -SplitTunneling $false 
    -AuthenticationTransformConstants GCMAES256 
    -CipherTransformConstants GCMAES256 
    -EncryptionMethod AES256 
    -IntegrityCheckMethod SHA384 
    -DHGroup Group14 
    -PfsGroup PFS2048 
    -Force

Windows 10 is particularly strict about certificates. Ensure your server certificate:

• Has a Subject Alternative Name (SAN) matching your server's FQDN
• Uses RSA with at least 2048-bit key
• Is issued by a CA that's trusted by the Windows client
• Has proper key usage extensions (Digital Signature, Key Encipherment)

If you're still facing issues, enable detailed logging on both ends:

On Ubuntu server:

sudo ipsec restart --debug-all

On Windows client, check Event Viewer logs under:

Applications and Services Logs > Microsoft > Windows > RasClient

If the built-in client continues to fail, consider using the strongSwan Windows Client which offers more configuration options and better compatibility.