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.
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.
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.
