ACI, TrustSec & ISE – Policy Plane Integration – Validation

The configuration was completed end to end in the previous post (ACI, TrustSec & ISE – Policy Plane Integration – Configuration). We will now go through the validation of the configuration by connecting the VPN client, accessing the server and checking all the components in the solution to ensure everything is as we expect.

Topology

The aim of this is for the VPN client to be able to connect to the server 10.255.255.1 via ICMP and SSH. The server is hosted in a vCenter/ESXi cluster connected and integrated with ACI. The IEPG has a provided contract allowing HTTP, HTTPS, SSH and ICMP and the EEPG ‘Contractors_SGT’ consumes this contract. The client IP will be added to the ‘Contractors_SGT’ EEPG as a host entry by ISE after the client has authenticated and the ASA has advertised the SGT-IP mappings via SXP.

VPN Client

The VPN client is a AD domain member, running Windows 10 Enterprise with Cisco AnyConnect to connect to the ASA via the ASA outside interface. As a reminder the client authentication is done via ISE and ISE uses an Active Directory backed External Identity Source where the VPN client user is a member of a Active Directory VPN group ‘VPN-CONTRACTORS’.

The usual process of connecting with the AnyConnect client by selecting the VPN endpoint and entering username and password for the user account in the AD domain. After authentication, the AnyConnect Posture module will run checking against the ISE policies for this machine. This is not directly related to the ACI integration but as we have policies setup in case posture validation fails, these policies for Posture.Unknown or Posture.NonCompliant also apply SG’s. So the posture to SG mapping looks like:

  • Posture.Compliant: SG=Contractors (ACi EEPG: Contractors_SGT)
  • Posture.Unknown: SG=Guests (ACI EEPG: Guests_SGT)
  • Posture.NonCompliant SG=Posture_Non_Compliant (ACI EEPG: Posture_Non_Compliant_SGT)

The SG’s Guest & Posture_Non_Compliant do not have any contracts applied in ACI so no access for these clients is permitted unless there are other EEPGs in the tenant with manual entires permitting these VPN networks. As discussed in the previous post, this should rarely be the case under any circumstance.

We have a VPN client connected with a posture status of Compliant.

Expectations

Now the client is successfully connected with a posture status of Compliant, the VPN client IP should have been mapped to the Contractors SG. This is done by the ASA VPN FW as this is the entry point into the TrustSec domain for this particular client as its via VPN.

ASA (VPN)

So first checking the firewall for a SGT-IP mapping, but reminding ourselves of the SG list which helps up map the SGT to a SG name.

vpn-uk# show cts environment-data sg-table

Security Group Table:
Valid until: 20:43:56 GMT/BDT Aug 12 2021
Showing 18 of 18 entries

SG Name                          SG Tag     Type
-------                          ------     -------------
ANY                               65535     unicast
APP_ISE_EPG_VPN_CLIENT_SERVERS_EPG  10001     unicast
Auditors                              9     unicast
BYOD                                 15     unicast
Contractors                           5     unicast
Developers                            8     unicast
Development_Servers                  12     unicast
Employees                             4     unicast
Guests                                6     unicast
Network_Services                      3     unicast
PCI_Servers                          14     unicast
Point_of_Sale_Systems                10     unicast
Production_Servers                   11     unicast
Production_Users                      7     unicast
Quarantined_Systems                 255     unicast
Test_Servers                         13     unicast
TrustSec_Devices                      2     unicast
Unknown                               0     unicast

Firstly check the ASA AnyConnect session for the user, which shows the assigned IP of 192.168.2.4 and also shows the assigned Security Group as SGT:SG Name (5:Contractors), So we know the client has been assigned the correct SG.

vpn-uk# show vpn-sessiondb anyconnect filter name simon@ad.labs.haystacknetworks.com

Session Type: AnyConnect

Username     : simon@ad.labs.haystacknetworks.com
Index        : 4
Assigned IP  : 192.168.2.4            Public IP    : x.x.x.x
Protocol     : AnyConnect-Parent SSL-Tunnel DTLS-Tunnel
License      : AnyConnect Essentials
Encryption   : AnyConnect-Parent: (1)none  SSL-Tunnel: (1)AES256  DTLS-Tunnel: (1)AES256
Hashing      : AnyConnect-Parent: (1)none  SSL-Tunnel: (1)SHA256  DTLS-Tunnel: (1)SHA1
Bytes Tx     : 453401                 Bytes Rx     : 102118
Group Policy : GroupPolicy_ClientPN   Tunnel Group : ClientPN
Login Time   : 17:54:33 GMT/BDT Thu Aug 12 2021
Duration     : 0h:03m:04s
Inactivity   : 0h:00m:00s
VLAN Mapping : N/A                    VLAN         : none
Audt Sess ID : c0a801050000400061155249
Security Grp : 5:Contractors

So checking the SGT-IP mapping, we should find the client IP address (192.168.2.4) mapped to the Contractors SG, which we do. The mapping is from 192.168.2.4 to SGT 5. As per the table above, we see 5 is indeed the SG Contractors.

vpn-uk# sh cts sgt-map

Active IP-SGT Bindings Information

IP Address          SGT   Source
================================================================
192.168.1.211         8   CLI-HI
192.168.2.4           5   LOCAL


IP-SGT Active Bindings Summary
============================================
Total number of    LOCAL bindings = 1
Total number of   CLI-HI bindings = 1
Total number of   active bindings = 2
Total number of    shown bindings = 2

We discussed the fact that we have a SG called Guests assigned to a client when the Posture has a status of ‘Unknown’, this status is usually present when the AnyConnect Posture module is running on the client to give a Posture Status result. So we would expect that as the Authorization Rule states if Posture.Status==Unknown, the assign the Guests SG. While the posture was being validated and the client was in this state before moving to Compliant, looking at the SGT-IP binding we find that the client 192.168.2.4 has a SGT of 6 which referring back to the above table is in fact SG Guests.

vpn-uk# sh cts sgt-map

Active IP-SGT Bindings Information

IP Address          SGT   Source
================================================================
192.168.1.211         8   CLI-HI
192.168.2.4           6   LOCAL


IP-SGT Active Bindings Summary
============================================
Total number of    LOCAL bindings = 1
Total number of   CLI-HI bindings = 1
Total number of   active bindings = 2
Total number of    shown bindings = 2

ASA (SXP Proxy)

As we discussed in the previous post, due to the restrictions around the ASA SXP configuration using a site to site VPN via an outside interface we added a local LAN SXP capable device (another ASA) to act as a SXP listener to the VPN FW and a speaker to ISE. On this ASA looking at the SGT mapping we validate that this SXP device has received the IP-SGT mapping from the VPN ASA.

First checking the SG table has been downloaded to the ASA.

vpn-uk-2# show cts environment-data sg-table

Security Group Table:
Valid until: 18:39:40 GMT/BDT Aug 12 2021
Showing 18 of 18 entries

SG Name                          SG Tag     Type
-------                          ------     -------------
ANY                               65535     unicast
APP_ISE_EPG_VPN_CLIENT_SERVERS_EPG  10001     unicast
Auditors                              9     unicast
BYOD                                 15     unicast
Contractors                           5     unicast
Developers                            8     unicast
Development_Servers                  12     unicast
Employees                             4     unicast
Guests                                6     unicast
Network_Services                      3     unicast
PCI_Servers                          14     unicast
Point_of_Sale_Systems                10     unicast
Production_Servers                   11     unicast
Production_Users                      7     unicast
Quarantined_Systems                 255     unicast
Test_Servers                         13     unicast
TrustSec_Devices                      2     unicast
Unknown                               0     unicast

Then checking the SGT-IP mapping table which shows that indeed the correct mapping appears for the VPN client IP 192.1682.4 to SGT 5 (Guests)

vpn-uk-2# show cts sgt-map

Active IP-SGT Bindings Information

IP Address          SGT   Source
================================================================
192.168.1.211         8   SXP
192.168.2.4           5   SXP


IP-SGT Active Bindings Summary
============================================
Total number of      SXP bindings = 2
Total number of   active bindings = 2
Total number of    shown bindings = 2

ISE

ISE SXP SGT-IP Mappings

The next step is to confirm that the ASA (Proxy) has sent the mapping to ISE. In ISE go to > Work Centers > TrustSec > SXP > All SXP Mappings. In the table we find that the mapping has been advertised to ISE.

ACI

EEPG Subnet (VPN Client)

So as ISE has the SGT-IP mapping, we should expect that with the ACI integration, that ISE has updated the ACI ‘ISE’ tenant L3out EEPG ‘Contractors_SGT’ by adding a subnet IPv4 host entry for 192.168.2.4/32 into the EEPG. We find that this is the case so ISE to ACI integration for TrustSec Policy Plane seems to be working correctly.

Contract

To complete the end to end check, validating we have the contract in place between the EEPG and IEPG

IEPG Providing Contract

EEPG Consuming Contract

And for good measure, has ACI seen the server VM reported from both vCenter (vmm) and seen traffic from the VM (learned), which it has as we can see in the IEPG Operational Tab.

VPN Client

Actual Test

Of course this would all be pointless if our client contractor could not connect to the server…

So everything looks to be in order from the VPN ASA to the ACI ‘ISE’ Tenant IEPG. Running a ping from the VPN client is successful as is SSH so we have a valid implementation.

One of the posture checks that the Windows Firewall is enabled. If we disable the firewall and attempt to connect again, as the VPN client device has AnyConnect installed with admin rights, the posture check detects the firewall is disabled and instructs the AnyConnect Posture client to re-enable it. This is done in the background and once complete the posture check is successful and access is granted as we have seen in the previous validation test.

We set the firewall to disabled whilst AnyConnect is disconnected.

Firewall Disabled Before VPN Connection

After connection of the AnyConnect, the posture module re-enables the firewall to be compliant and permit the user the access as previously seen with the user a member of the Contractors SGT.

Firewall Enabled by Posture Client

The second posture check is for a file – ‘c:/filecheck/file1.txt’, the posture will fail if this file does not exist. First the file is renamed to be non-compliant with the posture policy.

After connecting the client via AnyConnect, we find that the posture client has detected that the file does not exist and warns the user.

You can see the client pings to the contractor server are failing showing no access is permitted. e find that access to the server in ACI fails as the client is added to the security group Posture_Non_Compliant, this translated group to the ACI L3Out EEPG name is Posture_Non_Compliant_SGT which has no applied contracts, therefore denying all access to resources within the ACI infrastructure. We see the client is assigned to this SGT in ISE.

Simon Birtles

I have been in the IT sector for over 20 years with a primary focus on solutions around networking architecture & design in Data Center and WAN. I have held two CCIEs (#20221) for over 12 years with many retired certifications with Cisco and Microsoft. I have worked in demanding and critical sectors such as finance, insurance, health care and government providing solutions for architecture, design and problem analysis. I have been coding for as long as I can remember in C/C++ and Python (for most things nowadays). Locations that I work without additional paperwork (incl. post Brexit) are the UK and the EU including Germany, Netherlands, Spain and Belgium.

Leave a Reply

Your email address will not be published.