Configuring Windows GPO for 802.1x authentication

When using 802.1x authentication (wired or wireless) on a Windows computer joined to an Active Directory Domain, Windows Group Policies Objects (GPO) can deploy the Native Supplicant configuration. The native supplicant can use different authentication methods, the common method being PEAP/MSCHAPv2 which uses Username and Password authentication. Slightly less common due to the perceived complexity is EAP-TLS which uses computer and/or user certificates.

This blog post describes the configuration of PEAP/MSCHAPv2, this requires only valid username and password for successful authentication.

Group Policy Configuration

  • Create a new GPO (or if required modify an existing policy) link the policy to an OU that the computers will inherit the policy configuration
  • Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > System Services
  • Locate the Wired AutoConfig service and double click to edit
  • Select Define this policy setting
  • Ensure Automatic is selected as startup mode
  • Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Wired Network (IEEE 802.3) Policies
  • Right click and select Create A New Wired Network Policy for Windows Vista and Later Releases
  • Name the policy appropriately, e.g. Wired Authentication Policy
  • Click the Security tab
  • Select the desired Authentication Mode it would be recommended to use User or Computer authentication, in order for both the Computer and User to be authenticated in order to grant network access in order to process Computer and User Group Policies.
  • Select the authentication method, e.g. Microsoft: Protected EAP (PEAP)
  • Click Properties
  • Ensure Validate server certificate is selected
  • Select the Trusted Root Certification Authorities certificate is selected (this certificate must be present in the Trusted Root certificate store of the RADIUS server and the client computer)
  • Ensure the authentication method is Secured password (EAP-MSCHAPv2)
  • Leave other settings as default
  • Click Ok
  • Click Ok to complete the configuration


  • Apply the GPO to a test computer
  • Open the Services MMC and check the status of the Wired AutoConfig service, this needs to be running
  • Open the Local Area Connection Properties, if the service is running the Authentication tab will be present

Notice that configuration is not possible as this settings have been applied from the GPO previous configured.

If the Wired AutoConfig service is not started, the Authentication tab will not be present.

Confirm the Trusted Root Certificate is present in the Local Computer certificate store. This certificate should automatically be present if joined to the Active Directory Domain.

Assuming the RADIUS server is configured correctly and the same Trusted Root Certificate is trusted by the Computer and the RADIUS server. Refer to this previous blogpost that describes how to configure Cisco ISE for Wired 802.1x authentication.


Comparing DMVPN Phase configuration

Cisco DMVPN has 3 Phases; this post will simply cover the basic commands for each DMVPN Phase.

This previous blog post will describe DMVPN on more detail:- DMVPN Phase 3 Dual Hub

Basic Configuration

Continue reading “Comparing DMVPN Phase configuration”


VRFs can be used on a router acting as a VPN gateway in order to isolate the routing tables of encrypted and cleartext traffic. As default when not using VRFs all routes are within the global routing table. A Frontdoor VRF (FVRF) can be defined on the outside/WAN interface; all traffic within this VRF would be encrypted. An Inside VRF (IVRF) would be used for cleartext traffic defined on the interface(s) on the inside of the network.

In this blogpost scenario the Hub and Spoke routers will be configured as follows:-


  • The Hub router will use a DVTI (Virtual-Template)
  • The Spoke router(s) will be configured with an SVTI Tunnel Interface per IVRF (in this scenario 2 IVRFs will be used).
  • The Hub router will not accept more than 1 tunnel from the same source peer address, therefore a loopback interface per tunnel is defined on the spoke routers’ – this must be routable over the internet/WAN.
  • RSA Certificates will be used for authentication. The spoke routers’ will require a unique certificate per VRF
  • Authorization will be performed on the Hub, a unique value in the OU field will distinguish between the spoke tunnels, with the IKEv2 name-mangler feature extracting the OU value.
  • Multiple Local IKEv2 Authorization Policies will be defined on the Hub, the Policy name matching the exact value in the OU field in the spokes’ certificate. In this instance the OU value is the same as the IVRF, it does not need to the same name as the IVRF.
  • The Hub’s IKEv2 Authorization Profile will reference a unique AAA Attribute list, which will define the unique VRF to be assigned to the Virtual-Access interface dynamically created on the Hub.
  • The spoke router(s) will also perform Authorization, but the policy will be static configured (name-mangler not required)
  • IKEv2 Routing will be used for one VRF and EIGRP will be used for the other

This post does not cover the full configuration of FlexVPN, refer to the previous blog posts for more information:-

FlexVPN Hub and Spoke
FlexVPN Local Authorization
FlexVPN IKEv2 Routing
FlexVPN Certificate Authentication

Continue reading “FlexVPN VRF”

Cisco IOS Certificate Authority

A Cisco IOS Router can be configured as a Certificate Authority (CA), distributing and managing (revoking) digital certificates. IOS routers enrol with the PKI Server and issued a certificate for use during the authentication phase when establishing a VPN tunnel. When authenticating peers exchange certificates and validate the identity of the peer and if successful establish a secure IKE Security Association, through which an IPSec SA can be established.

The purpose of this post is to describe the steps to configure a basic PKI/CA Server on a Cisco IOS router.

Continue reading “Cisco IOS Certificate Authority”

FlexVPN Local Authorization

In this example FlexVPN Remote Access VPN users will authenticate to the Hub router using RSA certificates. Using the IKEv2 Name Mangler feature, the organisation-unit (OU) value will be extracted from the certificate and assigned a Local IKEv2 Policy based on the extracted value. The IKEv2 Policy name must match exactly the value defined in the OU. The IKEv2 Policy in conjunction with the AAA attribute list will assign different attributes to the users’ sessions, for example VRF, IP Pool, Access List etc.

This configuration is an example of FlexVPN Local Authorization, the same can be achieved using a RADIUS server. Refer to the previous posts for additional FlexVPN information:-

FlexVPN Certificate Authentication
FlexVPN external AAA with RADIUS
FlexVPN Hub and Spoke

Continue reading “FlexVPN Local Authorization”

ASA AnyConnect SBL

This post describes how to configure the Cisco ASA and AnyConnect VPN to use the Start-Before Logon (SBL) feature. This allows the user to connect to the VPN before logging onto Windows, thus allowing login scripts and Windows Group Policies to be applied.

Create/Modify the AnyConnect Profile

  • Open the AnyConnect VPN Profile Editor
  • Open the existing VPN Profile or create a new file
  • Under VPN > Preferences (Part 1) select User Start Before Logon
  • Ensure the Certificate Store is All
Continue reading “ASA AnyConnect SBL”

ASA Split Tunnelling

When using a Cisco ASA for Remote Access VPN (SSL-VPN or IKEv2/IPSec) with the AnyConnect client, in most typical scenarios ALL traffic from the AnyConnect VPN client is encrypted and tunnelled back to the ASA. When using the ASA as the VPN headend device with the AnyConnect client you can use split tunnelling feature, which can be configured to include or exclude certain networks from the VPN tunnel.

The basic configuration of a Remote Access VPN to tunnel all traffic back to the ASA

group-policy GP-1 internal
group-policy GP-1 attributes
dns-server value
vpn-tunnel-protocol ssl-client
split-tunnel-policy tunnelall
address-pools value VPN_POOL

On Windows the AnyConnect Route Details would indicate is a Secured Route, meaning all traffic is tunnelled back to the ASA.

Continue reading “ASA Split Tunnelling”