"Call Home List"

[Ping Zhou]

Can anyone help me understand the "Call Home List" in Posture Assessment with ISE 2.2?

Here is the snip from the AnyConnect Admin Guide, which says...

isco AnyConnect Secure Mobility Client Administrator Guide, Release 4.5 - Configure Posture [Cisco AnyConnect Secure …

"Call Home List—Enter FQDNs that you want to use for load balancing, monitoring and troubleshooting lookup, or for DNS mapped to the default Policy Service Node (PSN) in that node (if in a multiple scenario). When this is configured, the first probe for monitoring and troubleshooting lookup is sent to call home. You must configure this while migrating from a redirection to a non-redirection network."

So...do I need to create a new generic DNS FQDN record in my enterprise DNS server for it, such as posture-node.myplace.com, mapping to my PSN IP addresses?, or, can I just use my PSN FQDNs (or their interface IP addresses)?

How does the "enroll.cisco.com" work exactly, mentioned in this discussion?

ISE 2.2 or 2.3 Posture configuration

thanks!

[Nidhi]

You can use PSN IP address or their FQDN.

from the guide -

• During first probe AC posture module tries to establish with IP/FQDNs from "Call Home List". List of the targets for the probe has to be configured in AC posture profile on ISE side. You can define IPs/FQDNs separated by commas, with colon you can define port number for each Call Home destination. This port needs to be equal to the port on which client provisioning portal is runs. On the client side information about call home servers is located in ISEPostureCFG.xml, this file can be found in folder - C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ISE Posture\

ISE Posture Style Comparison for Pre and Post 2.2 - Cisco

[Craig Hyps · Accepted solution]

Yes, Call Home List could be list of accessible PSN FQDNs, or even LB VIP FQDN or Anycast IP that will direct query to one of multiple PSNs in a cluster.  The goal is to send user to any PSN that can perform the proxy lookup to MnT to determine session info which in turn is returned to client to access correct PSN and session info.

The FQDNs in the Call Home List will typically be customer specific.  The idea behind enroll.cisco.com is to allow a generic FQDN to be used for learning a target PSN IP.  Think of case where user moves between two organizations, domains or even ISE instances where the names in call home list are specific to given DNS domain or organization.

[Ping Zhou]

How does it work with the old "Discovery Host"? For my fully distributed ISE cluster, if all my PSNs listed in the "Call Home List" field, do I still need to input anything in the "Discovery Host" field? Please share some best practices. Thanks.

[Craig Hyps]

Discovery Host is used when NAD supports URL redirection.  This is generally preferred as it expedites the discovery process as part of Phase 1 and reduces load on other PSNs and MnT to look up session.

Note that DH should be a routeable target which triggers URL redirect, not the PSN IP/FQDN itself.  If try to send pacet directly to PSN in Phase 1 discovery, it will fail.

[Ping Zhou]

Make sense to me.

Just want to confirm one more point... Document ID:116143 , which was updated last Dec, has a suggestion on choosing DH, which states:

"""

Choosing the Discovery Host, one should take into the consideration, that the initial traffic from the

NAC Agent towards the Discovery Host should be visible to the PDP. So, good choices could be:

PDP address itself, non-existent host in the same subnet as PDP nodes.

"""

In this context, I believe PDP is just the old term for PSN. If I'm correct, that might just totally contradict your above clarification.

Here is the UR for your convenience.

Posture Services on the Cisco ISE Configuration Guide - Cisco

Thanks for clarification.

I read the admin guide. Do you know if here is any best practice paper for post 2.2 posture?

[hslai]

Our team are not recommending a PSN (or PDP) as the discovery host because it confuses folks when an ISE deployment has multiple PSNs. A PSN can be used as the discovery host, as long as the redirect ACL allows accessing to it (usually at HTTP port 80) and triggers the URL redirect.

Imran presented a session on ISE Posture Best Practices last week so you might consider reviewing the recording when it available.

Another good use of Call Host List is to put the configured port number of the client provisioning portal so the HTTPS requests use the correct certificate.

[Craig Hyps]

PSN should not be used as Discovery Host since the traffic that hits PSN for discovery is expected to be as a consequence of redirection.  Since traffic to PSN is often allowed by redirecting device (NAD), it will go straight to PSN and not on redirect port (8443 by default) to auth/discovery with session info.  As Hsing indicated, it could work if redirecting specific ports to PSN but often redirect ACL openly configured to allow all PSN traffic.    In summary, think of DH as a target that will force traffic to that target to traverse a redirection point, i.e. DH = target beyond redirect device.

Call Home list is opposite.  You want that traffic destined to PSN.

And by the way, the previously referenced doc is very old even though date indicates more recent update.  Maybe a posting date??  It is actually based on the original Posture Lab guide I wrote for ISE 1.0, but the info on discovery was not part of my original guidance.  The fact that it still references NAC Agent and refers to PSNs as PDPs are immediate indicators of its true age!

[craig.beck]

Would it be recommended to use LB VIP FQDN or IP for call-home where LB is used?

I've seen some instances where NAD does authc for client via one PSN but the client's policy server (in Anyconnect) shows as the other PSN in the node group.  Ultimately the result is that the CoA sometimes doesn't get sent, or does but contains an old session-id for whatever reason.

Just wondering if using persistence at LB and "match across VIPs" to direct client to the same PSN would mitigate this?