ACI, TrustSec & ISE – Policy Plane Integration – Configuration

The use of TrustSec with ACI can be implemented in two ways, Policy plane or Data plane. There are some distinct differences between these two implementation types. The second part of this article on Policy Plane integration validation is here.

Topology

The topology used here includes ISE which will interface with the ACI APIC using the REST API to retrieve the specified tenant EPGs, Note: I state the specified Tenant!. Policy plane integration with ISE only works with a single tenant, this is one key difference between Policy and Data plane integrations, this limitation does not exist in the Data plane implementation.

The physical topology we are using consists of two sites connected with an IPSec VPN. Site A hosts the ACI data center where ISE is hosted and also a Linux VM. Site B provides VPN client connectivity via an AnyConnect client to an ASA. In this case, the client is a contractor that needs to access the Linux server host on the DC at site A. As we will discuss in this article, the VPN ASA uses the public interface (outside) for VPN client and the S2S VPN, it also functions as a SXP v3 Speaker. Also present on site B is a second ASA serving an SXP v3 Listener and Speak role over separate connections.

The contractor VM is contained in an ACI tenant called ‘ISE’ with an IP of 10.255.255.1, the contractor needs to access this server with ICMP, SSH, HTTP & HTTPS. The contractor should only have specific defined access to DC resources, access will be maintained by TrustSec and not firewall rules for DC resources.

Workflow

A Windows 10 VPN client using AnyConnect connects to a Cisco ASA firewall where classification of the client by ISE Policy Sets and Authorization Profiles is performed checking posture and then classifying the client into a Security Group, this classification is reported back to the ASA from ISE.

ISE then propagates this classification, which is a SGT (Security Group Tag) to IPv4 (VPN client assigned IPv4 address from VPN IP pool) mapping to all the defined SXP listeners configured on ISE. Recall that the propagation of SGT-IP mapping also happens over the data plane where there are TrustSec capable devices able to understand the frame CMD (Cisco TrustSec Meta Data) bits. In this scenario the firewalls at Site A are not directly connected to TrustSec capable devices there SXP is important in this situation.

ISE also propagates the SGT-IP mapping to ACI via the REST API. The tenant must have its own dedicated L3Out, no use of a other tenant L3Outs will work including the common tenant. The L3Out EEPGs will have been pre-configured by ISE during the integration with all the Security Groups defined in ISE as L3Out EEPG’s (External EPGs – l3extInstP). The EEPG that has been created from a ISE Security Group and assigned to the client by ISE after successful login will have the client’s IP (/32) added to the EEPG subnets (l3extSubnet) with a scope of ‘External Subnets for External EPG’ (import-security).

At this stage, ACI has an EEPG with the client IP defined, so where traffic sourced from the client enters the tenant L3Out, ACI will use the policies applied to the EEPG. This is the start of enforcement as the client cannot use other EEPGs (if there no overlap/duplication of the client IP in any of the EEPGs in the L3out – which there should not be in most cases). The EEPG has a consumed contract permitting ICMP,HTTP,HTTPS,SSH which is being provided from a IEPG (Internal EPG) where the contractor VM resides which is what the client is permitted to access using those protocols.

The ACI tenant L3Out is connected to a non-TrustSec capable device so the reliance on SXP between ISE-FW and the REST API between ISE-APIC is important as in this example the TrustSec domain and path between the VPN client FW and ACI is not fully TrustSec enabled. Even if this were the case, the SXP flow and APIC REST calls would still be required as ISE programs the APIC and SXP sends the mapping to ISE from the FW via SXP.

That is the basic workflow the rest of this discussion will focus on.

We could also use a TrustSec SGACL capable border router connected to the ACI L3Out where we can apply ISE Security Group ACLs for the source SG (clients assigned SG) and the destination SG (EPG), in this scenario we don’t have this situation, if we did then the same process still needs to be followed when we are creating contracts between the ACI EEPG and IEPG. We will be discussing SGACLs in the Data plane integration article

Policy Plane Integration

As briefly mentioned, the policy plane integration is between ISE and ACI through the configuration of L3Out EEPG’s and EEPG’s subnets.

ISE & ACI Integration

ACI Tenant Configuration

We have a tenant named ‘ISE’ with an IEPG named ‘ EPG_VPN_CLIENT_SERVERS_EPG ‘ attached to a VMWare domain where the Linux VM is connected, this IEPG si connected to a VRF named ‘ISE’ and a bridge domain named ‘BD_SERVERS’. The BD has a subnet gateway configured with 10.255.255.254/24 and subnet controls are set to ‘Advertise Externally’. The BD also has the local tenant L3Out associated named ‘L3_OUT’ as the L3Out is in the same tenant.

The L3Out named ‘L3_OUT’ is configured in the ISE tenant as referenced by the BD ‘ BD_SERVERS ‘. OSPF is configured to exchange routes with the external border router, recall that this border router is not TrustSec capable and that in this scenario we dont require a TrustSec capable border router. We only create an EEPG called ‘default’ with a subnet of 0.0.0.0/0 and apply contracts for standard outbound external access for the contractor VM for example HTTPS, DNS, ICMP, NTP etc in the usual way where the EEPG provides this contract and consumed by the IEPG for the contractor VM. We do not configure any other EEPG’s in the L3Out as ISE will do this for us.

Finally, we configure a user account ‘svc-ise’ on ACI (local in this case) with tenant admin permissions to use on ISE. This is the account ISE will use to configure the ACI tenant L3Out. For user account, security a new Security Domain is created called ‘SD_TENANT’ and applied to the user ‘svc-ise’ with ‘tenant-admin’ write privileges. This Security Domain is added to the tenant ‘ISE’ Security Domains policy. So we have a user account for ISE with write permissions only in the ‘ISE’ tenant.

ISE Configuration

In ISE we configure the ACI policy plane configuration in > Work Centers > TrustSec > Settings > ACI Settings.

Check the box for ‘Enable ACI Integration’, this will display the configuration options for the ACI connection.

• Select the ‘Policy Plane/API Integration’ option
• Enter the FQDN or IP address of one of the APICs
  • One is fine as recall if any APIC in the cluster is down the APIC cluster goes into a read only state preventing changes
• Enter the admin name, in this case the ISE account setup on ACI called ‘svc-ise’
• Enter the password for the ‘svc-ise’ account
• Enter the tenant name, in our case ‘ISE’
• Enter the name of the L3out we created in the ISE tenant, in this case L3_OUT

The name convention requires a suffix to be appended to both IEPGs imported into ISE and SGT’s imported into ACI as EEPG’s. I would much prefer the flexibility to choose prefix or suffix but suffix is the only option. We leave them as the defaults in this case.

SXP Propagation allows us to create separate SXP domains which are effectively like distribution lists for SXP, so devices that are part of a named SXP domain will share those mapping within that domain context only. This is not segmentation like VRFs so IP space must still be unique across all domains. We will use the default domain which is the default under ‘Specific SXP Domains’.

Leave the Data Plane Integration options unchecked as we are of course using the Policy based approach.

On clicking Save, if all the above has been configured correctly and if you have the APIC UI open in the tenant L3Out and have opened the External EPGs folder, you can watch the SGTs configured on ISE being created as EEPGs with the suffix we configured as ‘{SGT-NAME}_SGT’. So this is of course ISE making some REST calls to ACI to create the EEPGs using the l3extInstP class. No magic here, its just standard REST API calls.

At the same time, ISE has also made some other REST calls to the APIC to get all the IEPGs of the tenant, which is a MO query against the tenant for all objects with a class of fvAEPg. If we take a look in ISE at > Work Centers > TrustSec > Components > Security Groups, we will see any ACI IEPGs in the tenant listed with the suffix ‘_EPG’, so in our case we see the name of the IEPG as ‘{Application Profile Name}_{EPG Name)_EPG’, so ‘APP_ISE_EPG_VPN_CLIENT_SERVERS_EPG’. The Security Groups list also includes all the configured SG’s which we have seen configured in ACI with the _SGT suffix.

So we now have successful bi-directional communication between ISE and the ACI APIC.

One last task before we move on. We need to create a contract in the ‘ISE’ tenant to permit traffic between the IEPG and EEPG, but which EEPG? The EEPG’s in the L3Out are actually the SGs from ISE as we have seen and as we are using a VPN client as an example, so we need to map the VPN Client IP to an SGT (EEPG). The VPN client will be mapped to the ‘Contractors’ SG. In the ACI tenant L3Out this has been created by ISE as ‘Contractors_SGT’. We will create this VPN client mapping a bit later, for the moment we need a contract provided from the IEPG ‘ EPG_VPN_CLIENT_SERVERS_EPG ‘ and consumed by the EEPG ‘ Contractors_SGT’ permitting HTTP, HTTPS, ICMP and SSH.

The configuration so far permits any inbound packet into the L3Out with a source address in the subnets configuration of the EEPG ‘ Contractors_SGT’ to access endpoints in the IEPG ‘ EPG_VPN_CLIENT_SERVERS_EPG’ destined for a TCP port of 80,443,22 or ICMP. We don’t have any IP’s in the subnets of the EEPG yet, ISE will do that for us when the VPN client goes through successful authentication and authorization.

ISE & ASA Integration

For ISE and ASA integration we have a few tasks to perform such as configuring the ASA as a network device in ISE to use RADIUS for Authentication, Authorization and CoA. We also configure the ASA again in ISE as an SXP device to exchange SG lists and SGT-IP mappings.

The ASA will use ISE RADIUS for authentication and authorization of the VPN client along as well as the client AnyConnect client using ISE for Posture checking.

ISE Configuration

Network Device Configuration

Configure the ASA as a network device in ISE, use the IP address on the ASA that is enabled for management access. Check the ‘RADIUS Authentication Settings’ to enable RADIUS between ISE and the ASA and enter the shared secret that will be used between ISE and the ASA. All other defaults can be left, CoA should be 1700.

Check the ‘Advanced TrustSec Settings’ to enable the TrustSec settings for the ASA on ISE.

• Check the ‘Use Device ID for TrustSec Identification’, which will use the device name as entered at the top of the Network Device configuration screen.
  • This device id is used in the PAC as an Initiator-ID, when the PAC created on ISE for the ASA is uploaded to the ASA and communication between the ASA and ISE is started, ISE will verify the PAC Initiator-ID against the network device configuration and this ‘Device ID’ to be sure the right device with the right PAC is connecting.
• Enter a password for the device, as for the device id it is used for PAC authentication.
• In the ‘TrustSec Notifications and Updates’ section
  • The ‘Download environment data every’ refers to the downloading of the list of SGs we saw on ISE, its possible to manually sync the list on the ASA and/or have ISE tell the ASA to pull periodically. What this means is that if you configure a new SG or EPG, its not automatically pushed to all devices. The time you set is really dependent on how dynamic your configuration is in terms of create/deleting SG/EPGs so set accordingly.
  • The ‘Download SGACL lists every’ does not apply to ASA’s as its down to the ASA administrator to define the SGACLs on the ASA separately.
• ‘Other TrustSec devices to trust this device’ does not apply in this senario as the ASA is not adding the SGT / CMD to the client VPN frames as its not connected to a TrustSec capable device.
• Enable ‘Send configuration changes to device’ and choose the ‘CoA’ option. CoA notifications are sent as RADIUS attributes, for example to update the SG list (environment data).

Finally we ‘Generate PAC’, adding a password and saving to the local machine. This will be imported manually into the ASA, currently the only option. For other TrustSec devices (routers, switches), this can be pulled from ISE via configuration.

This configuration will be used in our ISE Policy Sets, which we will come back to later.

SXP Configuration

First we need to make sure we have SXP enabled on ISE, in > Administration > Deployment select the ISE node the policy server is running on and check the ‘ Enable SXP Service’ and choose the interface that has access to the network devices that will peer with ISE using SXP.

To configure the ASA as an SXP device go to > Work Centers > TrustSec > Settings > SXP Settings.

• Ensure ‘Add radius mappings into SXP IP SGT mapping table’ is checked.
• Add a password to ‘Global Password’, this password is the one used by ISE when connecting to an SXP device. It can be overridden locally for each device.

Go to > Work Centers > TrustSec > Settings > SXP > SXP Devices to configure the ASA as a SXP device, click ‘Add’

• Enter the ASA hostname
• Enter the ASA IP address that ISE should use to connect to the ASA and the one the ASA uses to initiate SXP connections to ISE
• The ‘Peer Role’ is the role that the ASA will take in the SXP configuration, the ASA will be a ‘Speaker’ as it will send SGT-IP mappings to ISE after a successful VPN client connection. Note the ASA only supports SXP V3 so its not correct to set this as ‘Both’, it wont work.
• We discussed ‘SXP Domains’ earlier, so leave as ‘default’, but you can see this is how we define SXP domains with the earlier ACI integration.
• ‘Status’ needs to be ‘Enabled’
• ‘Password Type’ can be ‘CUSTOM’ where we provide a unique SXP password for ISE and the ASA, we can choose ‘DEFAULT’ as use the default password we entered in the SXP settings.
• ‘Version’ is the SXP version to be used, as discussed SXP V3 is the highest the ASA’s currently support.

ASA Configuration

AAA Radius Setup

aaa-server ISE protocol radius
 interim-accounting-update periodic 1
 max-failed-attempts 5
 dynamic-authorization
aaa-server ISE (inside) host 10.243.176.100
 retry-interval 1
 timeout 30
 key *****
 authentication-port 1812
 accounting-port 1813
 radius-common-pw *****
management-access inside

SXP Configuration

cts server-group ISE
cts sxp enable
cts sxp default password *****
cts sxp connection peer 192.168.1.7 password default mode local speaker
cts role-based sgt-map 192.168.1.211/32 sgt 8

Sequence Randomization (Disable)

SXP uses TCP-AO which is a TCP level authentication and message integrity feature which if passed through a firewall which performs TCP sequence number randomization will invalidate the packet causing SXP to fail. In this senario the ASA is providing the remote access VPN but also has a remote site VPN which is where ISE is located, so hair-pinning on the outside interface from client to ISE and ASA using outside interface site VPN. To fix this we disable sequence number randomization on the ASA.

!
object network ISE
 host 10.243.176.100
!
object-group network ASA_UK
 network-object object asa-uk-01
 network-object object asa-uk-02
!
access-list global_mpc extended permit tcp object ISE object-group ASA_UK
access-list global_mpc extended permit tcp object-group ASA_UK object ISE
!
class-map ise-class
 match access-list global_mpc
!
policy-map global_policy
 class ise-class
  set connection random-sequence-number disable
!

VPN Client Profile & Policy Group

So lets look at the specifics around the ASA VPN remote access profiles that matter in this setup. Firstly in the client connection profile we need to make sure we select the ISE server as the authentication and accounting server. This is not the full connection profile or group policy so please make sure you fully configure the remote access policies as well. The important items are ‘ authentication-server-group ‘ and ‘ accounting-server-group ‘.

tunnel-group ClientPN general-attributes
 address-pool VPN_192.168.2.0
 authentication-server-group ISE LOCAL
 accounting-server-group ISE
 default-group-policy GroupPolicy_ClientPN
tunnel-group ClientPN webvpn-attributes
 authentication aaa certificate

Ensure that the DNS servers provided to the VPN client are capable of resolving the ISE server FQDN, this is important if you are using Posture for your VPN client as ISE passes the ISE FQDN by default as the Posture server.

Checks

We need to check the RADIUS and SXP configuration is valid and working.

Validate RADIUS

vpn-uk# test aaa-server authentication ISE username simon.birtles@ad.labs.haystacknetworks.com password ************
Server IP Address or name: 10.243.176.100
INFO: Attempting Authentication test to IP address (10.243.176.100) (timeout: 32 seconds)
INFO: Authentication Successful

Validate SXP

We run a refresh command to have the ASA request the environment data which is actually the list of Security Groups from ISE.

vpn-uk# conf t
vpn-uk(config)# cts refresh environment-data
vpn-uk(config)# exit

Check we have a successful SXP connection with ISE. You may notice here that the Peer IP address is not the ISE address ! As ISE is at a remote site connected via a site VPN, SXP does not allow you to specify an inside address as the source and the outside address is a DHCP address so impossible to use, even so using an outside IP would cause the route from ISE to route outside the VPN which would not work. So 192.168.1.7 is actually an SXP capable device on the ASA inside network that runs as a listener to the ASA and a speaker to ISE. In a way a proxy but legitimate in terms of SXP protocol rules and this client server topology can be useful in large scale site deployments to relive the burden from other devices having many SXP connections (think full mesh vs partial mesh vs hub and spoke). SXP v4 covers this with loop protection, hence be careful with SXP v1,2,3.

vpn-uk# show cts sxp connections
SXP               : Enabled
Highest version   : 3
Default password  : Set
Default local  IP : Not Set
Delete hold down period  : 120 secs
Reconcile period  : 120 secs
Retry open period : 120 secs
Retry open timer  : Not Running
Total number of SXP connections: 1
Total number of SXP connections shown: 1
-----------------------------------------------------------
Peer IP           : 192.168.1.7
Source IP         : 192.168.1.5
Conn status       : On
Conn version      : 3
Local mode        : Speaker
Ins number        : 1
TCP conn password : Default
Reconciliation timer   : Not Running
Delete hold down timer : Not Running
Duration since last state change: 0:01:06:44 (dd:hr:mm:sec)

Check CTS refresh was successful.

vpn-uk# show cts environment-data
CTS Environment Data
====================
Status:                    Active
Last download attempt:     Successful
Environment Data Lifetime: 18000 secs
Last update time:          15:43:56 GMT/BDT Aug 12 2021
Env-data expires in:       0:04:59:46 (dd:hr:mm:sec)
Env-data refreshes in:     0:04:49:46 (dd:hr:mm:sec)

View the SG’s (Security Groups) have been downloaded. These SG’s are the same as we saw on ISE after the integration between ISE and ACI. You can clearly see the ACI IEPG (‘ APP_ISE_EPG_VPN_CLIENT_SERVER_EPG ‘) in the list.

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

So some other gotchas here too, ASA only supports SXP v3, which means a single SXP connection cannot be set to ‘both’ (Bi-Dir: speaker and a listener), so it must be one or the other. In addition if you try to configure the same SXP peer as a listener (as we already have one as a speaker), the ASA will reject it. Running partial mesh with v3 can be tricky and best avoided. The only issue here is the ASA wont have any SGT-IP mappings other than those of the VPN client (as it creates these) so the ability to create firewall rules based on SG is lost. Now if this was not a VPN client FW, we could set the FW up as a listener and ISE (or .7 proxy) as a speaker, that way the FW would get the all the SGT-IP mappings and we could create rules on the firewall using SGs as the source / destinations instead of the usual network objects based on IP’s.

Its something to keep in mind whilst designing the TrustSec domains. Maybe SXP v4 is on the way for the ASA… the future will tell.

ISE Policy Sets & Authorization Policies

Finally we need to tie in the VPN client authorization to map the client to a SG.

Authorization Profiles

Before we look at the policy sets, we need authorization policies to refer in the policy sets so, in > Policy > Policy Elements > Results > Authorization > Authorization Profiles we just need the basics here, an ACCESS_ACCEPT and the ‘Network Device Profile’ set to ‘Cisco’ and a name, here its AP_VPN_SECURE

Access Type = ACCESS_ACCEPT

As we are running posture checking too, there are a few other Authorization Profiles aptly named ‘AP_PostureUnknown’ and ‘AP_PostureNonCompliant’ which are self describing but provide different DACLs back to the ASA. Also we use the ISE provided ‘DenyAccess’ authorization profile for failed authentications.

Policy Sets

There is a specific policy set that applies to this scenario created to match the ASA Network Device (NAD) in ISE and then run through the associated authorization policies. All are important of course, but we want to be applying a Security Group to the authorization policy that is selected during the client login.

Each of the authorization policy rules have been assigned a Security Group, the AD_USER_SECURE is the rule that is applied if the VPN client user is a member of the Active Directory domain group VPN-SECURE, has passed authentication and the client posture status has reported Compliant. In this case ISE will send the ID and name for the Contractors SG to the ASA via RADIUS. The ASA will create a SGT-IP mapping [x:Contractors:192.168.2.x] and advertise this via SXP upwards to ISE. ISE will send this so any configured connected SXP listeners and also create a /32 host subnet (l3extSubnet) entry in the ACI EEPG ‘Contractors_SGT’ (l3extInstP).

We know have the configuration completed end to end, now we validate this by connecting the VPN client and checking all the devices have successfully implemented the configurations for the VPN client in the next article ACI, TrustSec & ISE – Policy Plane Integration – Validation.