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

I recently concluded my Cisco CyberOps Scholarship program on October 20, 2017. With the conclusion came the second (210-255) of the two test to achieve your CCNA CyberOps certification.

I am sitting to write this post after several weeks of having already sat for the exam. I want to cut to the chase and report that I failed. Not once, but twice. Yes twice. I went into the the test having taken the same steps for studying for all my tests.

1. Familiarize myself with the material
2. Note taking
3. Labs
4. Walk the blue print

Walking the blue print is probably the most important part, I know that if I can answer the material found on the blue print I would be able to answer the questions on the test. It was no different in this case. I was familiar, overly familiar. and.. I failed my first attempt. After posting a fail I immediately scheduled for a second attempt.

My second attempt was ten days away. I was still a bit down on myself from posting a fail but I went to take my test with assurance that I would pass my second attempt. Question 60, the last question of the test. I’m feeling good at this point, I used reasoning from my first failed attempt to justify my answers on the second attempt, I click finish… My heart sank. On the results screen read..

“We have regret to inform you…”

I was beside my self. I was upset and didn’t understand what had just happened. I called my fiance to tell her the results. She replied with comforting words, she assured me that I was still a great engineer despite failing the test. I felt embarrassed. An NP level engineer can’t pass an NA level test? I was broken for a day after posting my second fail.

I sat to compare my results from the two attempts. I posted a 792 on both attempts. Missing the mark of 820 by one or two questions. When comparing question categories, my results from my first attempt to my second showed that I had  increased in some areas and decreased in others. Based on these results, I realized that my failure wasn’t a fact of not understanding the technical material but perhaps it was the state of mind I was in when I had taken the tests.

It would have been nice to walk out the scholarship program with a new certification, but what really matters is that I have a much better understanding of security. This understanding will help with my daily operation as well as my career development. I will continue to learn as much as I can in all realms of IT. For now, I will wait before deciding to attempt the test again. For those of you studying for your certifications; keep going, work hard.

Mike