ISE integration with Meraki EMM

Mobile Device Management (MDM) software manages mobile devices, such as smart phones, tablets or laptop computers. MDM applications define security policies which all devices must adhere to. When combining an MDM solution such as Meraki EMM with Cisco ISE, ISE can act as an enforcement point, allowing/denying devices to connect to the network if compliant or non-compliant with the MDM Security Policies. This blog post describes the steps to integrate Meraki EMM and ISE.

Meraki EMM Configuration

For Meraki EMM and ISE to communicate, ISE must be configured with the Meraki URL and username/password to authenticate. The Meraki EMM configuration settings found:-

  • Login to the Meraki Dashboard
  • Navigate to Organisation > Configure > MDM
  • Locate the ISE Settings section
  • Make a note of the Setup URL, Username and Password
Continue reading “ISE integration with Meraki EMM”

ISE Wired dot1x Posture

Cisco ISE Posture validation is used to determine the health status of the endpoint authenticating to the network. A set of conditions and requirements are defined, consisting of security applications (Anti-Virus, Anti-Malware, Personal Firewall, Hotfixes, Disk Encryption, Registry entry etc) that should be running on the endpoint, these are defined by the organisation.

The Cisco AnyConnect ISE Posture agent runs on the endpoint. Upon initial connection the client authenticates to ISE and is matched against a Posture Unknown Authorization Policy, the AnyConnect module connects to ISE and receives the posture requirements. The AnyConnect client then performs a posture data collection and compares the results against the ISE Policy it downloaded, before sending the assessment results back to ISE. ISE determines whether the endpoint client is compliant or not. At which point a CoA (Change of Authorization) is sent and the client is re-authorized either as Compliant or Non-Compliant.

This document covers the configuration of ISE regarding Posture, Authorization Policies and DACLS and does not specifically cover configuring the basic ISE settings such as External Identity Groups, Certificates. Refer to the following posts, which cover in more detail the configuration of Wired dot1x.

Initial Cisco ISE Configuration
Configuring Wired 802.1x authentication with ISE
Configuring Windows GPO for 802.1x authentication

Continue reading “ISE Wired dot1x Posture”

FTD DNS Security

Cisco FTD DNS based Security Intelligence allows you to identify a suspicious DNS query and blacklist the resolution of the dubious domain. When using DNS security provided by the FTD, it blocks the request for the suspicious domain before an HTTP connection is even established, saving resources.

DNS Filtering can be performed in 3 ways: –

  • Cisco TALOS maintains a database of known bad DNS domains, these are updated and downloaded regularly by the FMC as a feed.
  • Filtered manually from the FMC Connection Events page using Global DNS Whitelist and Global DNS Blacklist.
  • A custom DNS Feed/List

A DNS Policy is defined which can take the following actions: –

Continue reading “FTD DNS Security”

FTD Remote Access VPN with Posture

As of Cisco Firepower FTD version 6.3 CoA (Change of Authorization) is now supported, this means FTD now supports ISE Posture.

Firepower FTD Configuration

This post does not describe how to configure the basics such as registering the FTD to FMC, IPS, configuring interfaces and routing etc. The post describes how to configure Remote Access VPN and how to integrate with ISE for authentication.

Configure VPN Address Pool

  • Navigate to Objects > Object Management > Address Pools > IPv4 Pools
  • Click Add IPv4 Pools
  • Create a pool with a suitable Name and define the IPv4 Address Range
  • Click Save once complete
Continue reading “FTD Remote Access VPN with Posture”

Configuring Windows Supplicant 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.

Continue reading “Configuring Windows Supplicant for 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”