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)
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 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.
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:-
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.
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:-
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
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 192.168.10.5 192.168.10.6 vpn-tunnel-protocol ssl-client split-tunnel-policy tunnelall address-pools value VPN_POOL
On Windows the AnyConnect Route Details would indicate 0.0.0.0/0 is a Secured Route, meaning all traffic is tunnelled back to the ASA.