Welcome to the first blog of the new year, sorry for the late start. I’ve been stuck in the trenches trying to figure out the application flow for the posturing module used in the AnyConnect client.
A client of mine is having mixed results when an endpoint authenticates and then attempts to posture to their network. Some of the symptoms that are experienced are as followed:
- Device and user authenticates, AnyConnect reports incorrect policy server
- User reports intermittent network interrupts during their working day
- User receives “Untrusted server blocked!” (certificate issue)
I’ve invested a lot of time absorbing and digesting Cisco’s documentation for Cisco ISE and AnyConnect and believe at this point I have a good understanding of it.
Here is what I found and how you can perform the same troubleshooting steps to help resolve your issues.
We are focusing on Posturing. So after Authentication and Authorization is successful, posturing begins. Posturing is just a way to ensure that your endpoints are complying to your companies network policies before gaining network access.
The AnyConnect Posture Module begins by initiating policy server detection. This is accomplished through a series of probes which are known as discovery probes.
There are three probes in total, and I will show you how they look.
Probe 1 – AnyConnect sends first discovery probe to the clients default gateway. This discovery probe along with the next two are HTTP GET requests to /auth/discovery.
This request will be intercepted by the switch that the client is connected to and present a redirect-url to the client. This redirect is that of your policy node. If your AC is unsuccessful it will attempt a second probe.
Reminder: this is all done in the background and is not known to the user
Probe 2 – AC sends second probe. A HTTP GET /auth/discovery to enroll.cisco.com. This FQDN needs to be successfully resolvable by DNS server. In VPN scenario with split-tunnel, traffic to enroll.cisco.com has to be routed through the tunnel.
Expected result for the probe is redirect-url to your policy nodes.
Probe 3 –HTTP GET /auth/discovery to discovery host. Discovery host value is returned from ISE during installation in AC posture profile. Expected result for the probe is redirect-url
Your AC posture profile lives here.
C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ISE Posture\ISEPosture.xml
Unfortunately none of these probes were successful for my client.
Posture would sometime succeed but not always. When it was successful the client was pointing to an old policy server in their old ISE 1.3 environment yet their clients were Authenticating to their new ISE 2.2 environment. hmm..
That turned out to be a key part in resolving their issue. My client had recently migrated from ISE 1.3 to ISE 2.2. ISE 2.2 changes the way posturing works.
Posturing in ISE 2.2 assumes that redirects are not needed but does support backwards compatibility for environment that use redirects.
I won’t be going into detail on how posture work in ISE 2.2. But do know that there are two stages.
Stage 1 uses the same traditional discovery probes that we listed above for backwards compatibility.
Stage 2 uses two discovery probes.
Probe 1 – Attempts to discover your PSN through IP/FQDN from the “CallHome list” that are defined in your posture profile located in
C:\ProgramData\Cisco\CiscoAnyConnect Secure Mobility Client\ISE Posture\ISEPostureCFG.xml
Probe 2 – AC tries the PSN FQDNs. It generates what should be a dynamically created file (ConnectionData.xml) upon first posture attempt. That file is located here.
C:\Users\<currentuser>\AppData\Local\Cisco\Cisco AnyConnect Secure Mobility Client\
The goal of both probes is to get FQDN. They are both there in the case where you don’t have your “CallHome List” defined for the first probe to succeed.
So after knowing this. I reference ConnectionData.xml. The .xml file had current ISE 2.3 and Old ISE 1.0 FQDNs.
I could delete and modify this file to exclude old ISE 1.0 FQDNs but it would reappear upon the next posture. I continued my troubleshooting.
I deleted ConnectionData.xml. I uninstalled the posture module from the client. I had the client re-posture so that I would receive the installation of the posture module.
I then referenced my newly dynamically generated ConnectionData.xml and bam! The .xml file only had ISE 2.3 FQDNs. It had no knowledge of old ise. Come to find out, the customer had a off line deployment package that included the ConnectionData.xml file and placed it in C:\Users\<currentuser>\AppData\Local\Cisco\Cisco AnyConnect Secure Mobility Client\…..When AnyConnect is deployed off-line and includes the .xml file, it creates a static entry in the file even though that file is rebuilt at each posture.
After fixing the discovery probes which was to enable http server on the default gateway where the hosts live and correcting the .xml file to exclude old ISE FQDNs. Clients were posturing to new ISE.
It’s been a long journey in this discovery but things are looking up.
Mike
