I've managed to get strongswan running with eap-mschapv2 authentication using a server certificate. Now I want to try and use the eap-radius plugin with NPS running on a Windows 2012 R2 server to authenticate against Active Directory.

On the domain controller I created a new user, and group (VPN_USERS) for remote access.

On the VPN server if I check out the syslog I see the following;

vpn charon: 08[IKE] received cert request for "C=US,O=CR-51 Test,CN=Root CA" 
vpn charon: 09[CFG] selected peer config 'ikev2-vpn'
vpn charon: 09[IKE] authentication of 'vpn.cr-51-test.local' (myself) with pre-shared key
vpn charon: 09[ENC] generating IKE_AUTH response 1 [ IDr AUTH EAP/REQ/ID ]
vpn charon: 09[IKE] successfully created shared key MAC 
vpn charon: 11[JOB] deleting half open IKE_SA after timeout

On a Windows 10 client get the following error during connection attempts:

dialed a connection named IKEv2 which has failed. The error code returned on failure is 13801.

On the NPS server in eventviewer there is an entry stating that the Network Policy Server denied access to a user and suggest changing the user's dial in settings in AD to allow access or to allow NPS to control access. It was originally set to allow NPS to control access and still fails when set to allow access.

Also I can not login with accounts on the domain controller other than a domain admin account after setting up NPS.

Heres the current configurations


config setup
  charondebug="ike 2, knl 2, cfg 2, net 2, esp 2, dmn 2, mgr 2"

conn ikev2-vpn



  [email protected]




(Just the sections I've modified)

load = yes
secret = testpass
server =


vpn : RSA "/path/to/key"
: PSK "testpass"

NPS configuration:

The NPS server is registered to the domain.

Freindly name: vpn
Addresss (IP or DNS):
Shared secret: testpass

Connection Request Policy

Type of network access server: Remote Access Server(VPN-Dialup)

  NAS Port Type: VPN
  Client Friendly Name: vpn

Network Access Policy

Type of network access server: vpn

   NAS Port Type: VPN
   Client Friendly Name: vpn
   User Groups: VPN_USERS

   Authentication Methods: EAP-MSCHAP v2
   NAS Port Type: VPN


NPS Error

Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 6/22/2018 5:25:02 PM Event ID: 6273 Task Category: Network Policy Server Level: Information Keywords: Audit Failure User: N/A Computer: nps.cr-51-test.local Description: Network Policy Server denied access to a user.

Contact the Network Policy Server administrator for more information.

User: Security ID: CR-51-TEST\tuser Account Name: [email protected] Account Domain: CR-51-TEST Fully Qualified Account Name: CR-51-TEST\tuser

Client Machine: Security ID: NULL SID Account Name: - Fully Qualified Account Name: - OS-Version: - Called Station Identifier:[4500] Calling Station Identifier:[4500]

NAS: NAS IPv4 Address: NAS IPv6 Address: - NAS Identifier: strongSwan NAS Port-Type: Virtual NAS Port: 4

RADIUS Client: Client Friendly Name: vpn Client IP Address:

Authentication Details: Connection Request Policy Name: Use Windows authentication for all users Network Policy Name: - Authentication Provider: Windows Authentication Server: nps.cr-51-test.local Authentication Type: EAP EAP Type: - Account Session Identifier: - Logging Results: Accounting information was written to the local log file. Reason Code: 48 Reason: The connection request did not match any configured network policy.

Event Xml: 6273 1 0 12552 0 0x8010000000000000 531 Security nps.cr-51-test.local S-1-5-21-2365315230-2476318153-1929964036-1111 [email protected] CR-51-TEST CR-51-TEST\tuser S-1-0-0 - - -[4500][4500] - strongSwan Virtual 4 vpn Use Windows authentication for all users - Windows nps.cr-51-test.local EAP - - 48 The connection request did not match any configured network policy. Accounting information was written to the local log file.

strongswan Error

enter image description here

3 Answers 3


Combining EAP with preshared-key authentication is not strictly valid according to RFC 7296:

Typically, these methods are asymmetric (designed for a user authenticating to a server), and they may not be mutual. For this reason, these protocols are typically used to authenticate the initiator to the responder and MUST be used in conjunction with a public-key-signature-based authentication of the responder to the initiator.

Some implementations, such as strongSwan, allow configuring it but lots of others don't, and will insist on authenticating the server with a certificate.

Since you already seem to have a certificate and private key, you might only need to set leftauth=pubkey. Provided that the client already has the CA certificate installed.

  • Thanks for the reply. Setting leftauth=pubkey I get the same errors in the logs as when I comment out the leftauth bit: in syslog on the vpn server: received RADIUS Access-Reject from server primary, and on the NPS server in the logs it states that no matching network policy was found.
    – 0B51D14N
    Jun 22, 2018 at 21:37
  • Yes, pubkey is the default, so commenting out leftauth is the same. Could you please update your question and add more details on the exact error you see in the NPS logs (and the current strongSwan logs wont hurt either)? Maybe the username is wrong (did you specify the domain?), or the authentication config associated with it, or maybe NPS wants to do the EAP-Identity exchange itself (you could try enabling the eap_start option in eap-radius.conf and comment out the eap_identity option in ipsec.conf).
    – ecdsa
    Jun 25, 2018 at 8:12
  • I added the current error logs to the question. Also, when I enable eap_start in eap-radius.conf and comment out eap_identity in ipsec.conf NPS gives the following error: The RADIUS Request message that Network Policy Server received from the network access server was malformed
    – 0B51D14N
    Jun 25, 2018 at 19:44
  • OK, then it doesn't understand the EAP-Start message, that's fine. How does the configured network policy look like? Does it set any EAP types (e.g. EAP-MSCHAPv2) as authentication method?
    – ecdsa
    Jun 26, 2018 at 7:23
  • I have EAP-MSCHAPv2 enabled in the network policy. it looks like its not using the network connection request policy I have configured and using the one that NPS made by default; "Use Windows authentication for all users". If I disable that default request policy I get the same error.
    – 0B51D14N
    Jun 26, 2018 at 16:29

So I disabled the policies I made for VPN connections on the NPS server and modified the default ones that NPS made with minimum constraints and I was able to successfully authenticate Active Directory users over the strongswan vpn. These polices should be fine as a starting point for testing.

On the strongswan VPN server

As ecdsa suggested in ipsec.conf I set leftauth=pubkey.

On The NPS

  • Under Connection Request Polices enable the Use Windows authentication for all users policy.
  • Under Network Polices disable Connections to Routing and Remote Access server
  • Enable Connections to other access servers under Network Polices
  • Right click Connections to other access servers and select Properties
  • Modify the Connections to other access servers policy:

Ensure Grant access is selected


I'm not sure if it was necessary but I also commented out the rightgroups parameter I set in the ipsec.conf file since strongswan was complaining about it in the logs.


For those looking for a solution more robust than simply allowing all kind of connections onto the NPS server, there is a simple setting you need to change and it works perfectly with strongSwan.

As for the reason this changes everything, I am not sure why. I am thinking this is simply because the policy created with the wizard assumes our client (the VPN server) is an OEM standard hardware, which comes pre-configured with settings which would make it send additional flags that would identify it has a "Remote Access Server(VPN-Dial up)". Really to that point, if anyone has clear explanations on that, it would be really appreciated. Either modify the answer or leave a comment. Thanks.

So, to start over with, click on the "NPS (Local)" root node, then in the main pane, click on "Configure VPN or Dial-Up". Follow the steps as you would do normally. When you're done with the wizard, 2 policies will be created with the name you have provided; One in "Connection Request Policies" and the other in "Network Policies". On both policies, in the "Overview" tab, the section "Network connection method", there is the option "Type of network access server" set to "Remote Access Server(VPN Dial up)". Change this option to "Unspecified". And that's all. Making that change for me was the only thing to be done in order to make the client request access properly. Both policies will be taken into account after that.

Hope it helps.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .