AnyConnect ISE posture module discovery host and call home list

There are two components of the AnyConnect ISE posture module profile (Work Centers > Posture > Client Provisioning > Resources) that I get more questions about than any other. One is the call home list discovery host and the other is the discovery host.

The Call Home List

What the heck is the Call Home List used for in the AnyConnect ISE posture profile? The description when you configure it is:

A list of IP addresses, that defines the all the Policy service nodes that the agent will try to connect to if the PSN that authenticated the endpoint doesn’t respond for some reason.

The is a very simple explanation but not very descriptive. To really understand the use of the Call Home List (as well as the Discovery Host), we need to look at the posture flow before and after Cisco ISE 2.2. If you want to see the full run down of how it changed with ISE 2.2, you can find a detailed write up here:

ISE Posture Style Comparison for Pre and Post 2.2

Let’s break it down to why the Call Home List came about and why it’s useful.

Posture module initialization pre-ISE 2.2

You log onto the network and the authorization rule you’re assigned requires posture assessment. AnyConnect launches and the ISE posture module starts running. In order to discover if posture assessment is required, the posture module initiates 4 probes to detect the client provisioning portal. The four probes are:

  • HTTP GET auth discovery to the default gateway IP
  • HTTP GET auth discovery to enroll.cisco.com
  • HTTP GET auth discovery to the configured Discovery Host
  • HTTP GET status check (SSL on TCP/8905) to previously connected PSN

The first three probes rely on a redirect ACL and URL to be present. The final probe is only initiated on a 2nd run of the probes if the first three fail the first time.

These probes present a problem with 3rd party network access devices (NAD). The dynamic redirect URL usually assigned in an authorization profile is supported on Cisco NADs but fails on 3rd party NADs. So to make posture work on 3rd party NADs you either had to utilize static redirect URLs or configure the DNS and DHCP services in Cisco ISE to create an Auth VLAN. There is a rare instance in distributed deployments when the client is authenticated on the same PSN that previously authorized (postured) the endpoint so a redirect URL wouldn’t be required but don’t rely on that.

Posture module initialization post-ISE 2.2

In ISE 2.2, we still have the same four probes from above (stage 1) but two new probes have been added (stage 2). These new probes are:

  • Call Home List: Comma separated list of FQDNs and port numbers (FQDN and port number separated by colon). The port number is whatever port is configured for the client provisioning portal. The default port number is TCP/8443 if it is not specified in the list. The PSNs are accessed in the order in which they are presented in the list.
  • ConnectionData.xml: This XML file contains a list of PSNs which the posture module should attempt a connection if the Call Home List is empty or fails. This file is created the first time a successful posture connection is made.

The biggest advantage of these new probes is adding more support 3rd party NAD posture redirection. Cisco ISE also gained the ability to find the session owner if the PSN used in either probe is not the same PSN that owns the authentication session. The process is:

  • AC posture module sends client information to the PSN found in the CHL or ConnectionData.xml file. If that PSN is the session owner, posture assessment occurs with the connection to the PSN on TCP/8905.
  • If the PSN contacted is not the session owner, the PSN queries the MNT to find who owns the session. The MNT responds with who owns the session and the PSN notifies the client with the FQDN of the session owner. The client then connects to the right PSN for posture assessment and reporting.

While it is nice to have the Call Home List, caution should be use not to utilize a single list of PSNs. Some form of load balancing should be utilize. That could mean multiple posture modules profiles based on locations or utilizing a load balancer.

What is the Discovery Host?

The description simply states “The server that the agent should connect to” which causes some confusion. Most of the time, people think it means the ISE Policy Service Node (PSN). This is not correct. The discovery host is used when the posture module initializes and initiates a probe (described above) to detect if a client provisioning portal is present.

So what should be placed in this field? You can leave it blank if you want but a better practice is to place a URL that will trigger a connection (ie a resolvable name). The AnyConnect client already tries enroll.cisco.com so you use an internal URL like www.company.com or an external URL like www.google.com. It really doesn’t matter as long as the name can be resolved and the redirect URL is triggered.

Share this post:

4 comments

  1. Great post as always. As you stated, enroll.cisco.com is always probed anyways, so if we ensure in the nad posture redirect acls that redirect is triggered on enroll.cisco.com/and its IP, is there a value of custom discovery host at all in any scenario?

    1. Mainly to give a second URL that is resolvable by the client in order to initiate a connection in case the first 2 probes fail for some reason.

  2. Some good information here. Wondering about the case for having the posture module installed but the ISE policy does not require posture. Client is authorized but the module finds the PSN and does a scan anyway and fails due to policy conditions not met. An knowledgeable user might not understand that they are not required to do anything. Just cancel the message.

  3. FYI, I hope this helps someone someday, as I banged my heads against the walls…

    Turns out that the FQDN to IP mapping for ISE posture is done via CLI, using commands like:
    ip host x.x.x.x name1.domain.ext
    ip host y.y.y.y name2.domain.ext

    Then, the posture redirect authorization policy will know to send out to the VPN Client a redirect URL with FQDN instead of the interface IP, so that the VPN Client will not complain anymore for mismatching SSL certificate (which is usually signed for an FQDN and not an IP address)

    Cheers!

Leave a Reply

Your email address will not be published. Required fields are marked *