Back
Lesson 2 of 6

AnyConnect Posture Module

Objective

Configure the AnyConnect posture (HostScan) module and client provisioning policies so endpoints receive posture checks and compliance information during VPN connections. This lesson shows how to place posture resources on the Secure Firewall (ASA/FTD) and how to align AnyConnect client provisioning with ISE posture decisions — including troubleshooting points such as AnyConnect package version ordering and port 8443 connectivity.

Topology

Refer to the topology deployed in Lesson 1. This lesson does not add new devices or interfaces; it reuses the same ASA/FTD and ISE pair from Lesson 1. No new IPs are introduced in this lesson.

Tip: If you missed Lesson 1, return to it before continuing. The ASA/FTD <-> ISE relationship and reachability on management and posture ports (notably TCP/8443) are prerequisites.

Device Table

DeviceRole
ASA/FTDVPN concentrator and host for AnyConnect & HostScan resources
ISE PSN / PANPosture decisioning, compliance module management, and detailed posture reporting
EndpointAnyConnect client that receives posture checks

Introduction

In this lesson we deploy the AnyConnect posture module (HostScan / compliance module) and configure client provisioning policies that determine when an endpoint receives posture checks. In production, posture enforcement is how organizations ensure endpoints meet minimum security standards before granting full network access — for example, ensuring AV is installed and up-to-date before placing a device on the internal network. Real-world scenario: a remote worker connects via AnyConnect; ISE evaluates posture and the ASA/FTD serves the posture resources to the client and enforces the authorization profile returned by ISE.

Quick Recap

  • Topology from Lesson 1 is used (ASA/FTD connecting to ISE).
  • Ensure ASA/FTD and ISE can communicate over posture-related ports (notably TCP/8443) and that any intermediate firewall is permitting this traffic.
  • The posture lifecycle includes: resource provisioning (HostScan/compliance module), AnyConnect client receiving module, endpoint scan, ISE posture evaluation, and enforcement via authorization profile.

Key Concepts

  • Posture Module (HostScan / Compliance Module): A client-side component delivered by the ASA/FTD that performs checks (AV installed, patch state). Think of it like a health-check app the VPN client runs before allowing full access.
  • Client Provisioning: AnyConnect profiles and provisioning policies define which agent types (AnyConnect, Stealth, Temporal, Agentless) are delivered and under what conditions. In production, this controls bandwidth and UX trade-offs (e.g., push posture only to Windows clients).
  • Version Ordering (Why it matters): If ISE advertises a higher AnyConnect package version than the ASA/FTD can serve, the client update can fail. Typical rule: ideally ASA/FTD and ISE should have the same AnyConnect package versions — mismatch leads to update errors.
  • Port 8443 and Posture Traffic: ISE PSNs receive posture data over TCP/8443. If packets are blocked or not reachable, posture will remain pending on ISE and the ASA/FTD will not receive posture reports — resulting in pending/failed posture decisions.
  • macOS utunX behavior: macOS VPN adapters (utunX) do not have a default gateway by default; this can affect split-tunnel or full-tunnel posture flows. In production, be aware posture over VPN for macOS sometimes needs policy tweaks.

Step-by-step configuration

Step 1: Upload AnyConnect and Posture (HostScan / Compliance) packages to ASA/FTD

What we are doing: Place the AnyConnect client package and the HostScan (posture) package on the ASA so the firewall can serve them to connecting clients. This is required before the ASA can push posture modules to endpoints.

enable
configure terminal
# (Example) Copy AnyConnect and HostScan images into flash (assumes TFTP server with packages)
copy tftp://10.0.0.100/anyconnect-win-4.x.x-k9.pkg disk0:/anyconnect-win-4.x.x-k9.pkg
copy tftp://10.0.0.100/hostscan-win-<version>.pkg disk0:/hostscan-win-<version>.pkg
end
write memory

What just happened: The copy tftp: commands transfer the AnyConnect and HostScan packages from a TFTP server into ASA disk0:. These files are required for ASA to serve the AnyConnect client and the posture module during client provisioning. write memory saves the running configuration so the ASA keeps reference to these resources across reloads.

Real-world note: In production don't use anonymous TFTP for package distribution; use secure file transfer methods and ensure packages are vendor-signed and verified.

Verify:

dir disk0:
# Expected output (example)
Directory of disk0:/

  1  -rw-   12345678  Feb 01 2024  anyconnect-win-4.x.x-k9.pkg
  2  -rw-    2345678  Feb 01 2024  hostscan-win-<version>.pkg
  3  -rw-       4096  Feb 01 2024  anyconnect-profile.xml

Step 2: Configure AnyConnect image and enable AnyConnect on the outside interface

What we are doing: Tell the ASA which AnyConnect image to serve and enable AnyConnect on the external interface used for VPN. The ASA must be able to deliver the client binary during initial connection.

enable
configure terminal
webvpn
 anyconnect image disk0:/anyconnect-win-4.x.x-k9.pkg 1
 anyconnect enable outside
exit
end
write memory

What just happened: webvpn anyconnect image registers the AnyConnect package with ASA under image index 1. anyconnect enable outside activates the AnyConnect VPN feature on the ASA's outside interface so remote clients can negotiate SSL/TLS VPNs and download resources. Internally the ASA will advertise this image during the SSL handshake when a client needs to be provisioned.

Real-world note: If you operate multiple ASA clusters, ensure consistent AnyConnect image indices to avoid client confusion when failover occurs.

Verify:

show running-config webvpn
# Expected output (excerpt)
webvpn
 anyconnect image disk0:/anyconnect-win-4.x.x-k9.pkg 1
 anyconnect enable outside

Step 3: Configure HostScan (posture) resources and associate with AnyConnect profile / group-policy

What we are doing: Register HostScan resources with the ASA and configure the group-policy or AnyConnect profile to request the posture module during client provisioning. This ensures the endpoint receives the posture engine and runs checks before full access.

enable
configure terminal
webvpn
 hostscan enable
 hostscan package disk0:/hostscan-win-<version>.pkg
 exit
group-policy NHPREP_GP internal
group-policy NHPREP_GP attributes
 webvpn
  anyconnect profiles value NHPREP_Profile
  hostscan value hostscan-win-<version>.pkg
exit
tunnel-group NHPREP_TG type remote-access
tunnel-group NHPREP_TG general-attributes
 default-group-policy NHPREP_GP
exit
end
write memory

What just happened: hostscan enable and hostscan package place the posture package under the ASA's webvpn hostscan configuration. The group-policy NHPREP_GP is configured so that clients using the NHPREP_Profile will be provisioned to download the HostScan package. The tunnel-group associates the VPN connection with the group-policy so that users who authenticate to NHPREP_TG receive the posture module.

Real-world note: Group-policies are often used to segment posture behavior — e.g., different posture requirements for corporate laptops vs contractor devices.

Verify:

show running-config group-policy NHPREP_GP
# Expected output (excerpt)
group-policy NHPREP_GP internal
 group-policy NHPREP_GP attributes
  webvpn
   anyconnect profiles value NHPREP_Profile
   hostscan value hostscan-win-<version>.pkg

Step 4: Configure ISE client provisioning and compliance module references (ISE GUI steps described; verify with logs)

What we are doing: On ISE, configure the AnyConnect client provisioning policy and the posture (compliance) settings so ISE knows which posture checks to perform and can instruct ASA about which authorization profile to return. This step is done in the ISE GUI (PSN/PAN) — below are the required actions and how to verify via ISE logs and reports.

  • In ISE GUI:
    • Navigate to Client Provisioning > AnyConnect Profiles (or equivalent) and add/confirm profile named NHPREP_Profile (matching ASA profile).
    • Under Posture > Posture Policies, create a posture policy which references requirements such as "Symantec X INSTALLED AND Symantec X UP_TO_DATE".
    • If using a compliance module (OPSWAT/OESIS), import the compliance module DB/application actions into ISE so posture checks map to requirements.

What just happened: The AnyConnect profile on ISE must match the ASA profile name so clients are provisioned consistently. Posture policies define the requirements the PSN evaluates. Compliance modules provide vendor signatures/rules to detect installed security products.

Real-world note: The compliance module often needs manual updates loaded into ISE. Also, the posture module on the client may not be updatable over the VPN if ISE advertises higher versions than ASA can serve; keep ASA and ISE AnyConnect/HostScan packages aligned.

Verify (on ISE GUI and PSN logs):

# On ISE PSN check: show posture reports via GUI; CLI verification example (PSN debugging)
show application status ise
# Expected output (example)
Application Status: ISE (running)
Posture Service: active
Last posture scan: 2024-03-28 10:12:45
Number of posture reports processed: 124

Also verify detailed posture report in ISE GUI:

# Expected fields in Posture Assessment Report (GUI)
- PSN name: PSN1
- Decision: Compliant / Non-Compliant
- Requirements matched:
  - Symantec X INSTALLED: Passed
  - Symantec X UP_TO_DATE: Passed
- List of detected security products:
  - Symantec X (AM) Version: 14.2.1 Definition: 2024-03-15
- Last posture scan time: 2024-03-28 10:12:45

Step 5: Troubleshoot common posture-blockers (port 8443, version mismatch, third-party firewall)

What we are doing: Validate connectivity between ASA and ISE PSN on posture port(s), check AnyConnect/HostScan version ordering, and inspect ISE live logs to confirm posture report arrival.

# On ASA/FTD: confirm connectivity to ISE PSN over TCP/8443 (example using ping/telnet-like check)
telnet 10.0.0.10 8443
# Or (if available) use packet capture for TCP/8443
capture posture-cap tcp any host 10.0.0.10 eq 8443
# On ISE: check live logs via GUI; on PSN show application status
show application status ise

What just happened: Attempting a TCP connection to port 8443 confirms whether posture reports can be delivered between ASA and the ISE PSN. Packet capture on ASA can reveal whether posture packets are blocked before reaching the PSN. ISE live logs and the detailed authentication report will show pending posture states and any redirect attributes returned to the NAD.

Real-world note: Many production posture failures are due to middle-boxes blocking TCP/8443. When posture is pending in ISE and no posture reports arrive, check for blocking rules in endpoint security, local firewall, or network firewalls near the PSN.

Verify:

# Expected output for a successful TCP test (telnet style)
Trying 10.0.0.10...
Connected to 10.0.0.10.

# Expected capture output (show capture)
show capture posture-cap
# Expected sample lines
00:00:01.234 192.0.2.50.53210 > 10.0.0.10.8443: Flags [S], seq 123456789, win 65535
00:00:01.456 10.0.0.10.8443 > 192.0.2.50.53210: Flags [S.], seq 987654321, ack 123456790, win 64240

If packets do not cross the switch or are blocked, the capture output will show no TCP 8443 traffic.

Verification Checklist

  • Check 1: ASA is hosting AnyConnect and HostScan packages — verify with dir disk0: and show running-config webvpn.
  • Check 2: AnyConnect HostScan is associated with the group-policy/profile used by remote users — verify with show running-config group-policy <name>.
  • Check 3: ISE received posture reports and returned a posture decision — verify via ISE GUI Posture Assessment Report and show application status ise on PSN.

Common Mistakes

SymptomCauseFix
Posture remains "Pending" in ISETCP/8443 is blocked by an intermediate firewall or endpoint firewallOpen/allow TCP/8443 between ASA/FTD and PSN; verify with packet capture
Client fails to download updated AnyConnect/HostScanISE advertises higher AnyConnect/HostScan version than ASA/FTD can serveSynchronize versions: update ASA/FTD packages to match ISE, or configure ISE to defer update; ensure consistent package versions
macOS clients show limited posture behaviormacOS utunX interface has no default gateway and posture over VPN may be affectedAdjust client provisioning/policies for macOS, test split/full-tunnel behavior; ensure the posture module supports macOS
No detection of security products in posture reportCompliance module DB not uploaded to ISE or posture policy not mapping requirementsUpload the compliance module (OESIS/OPSWAT DB) to ISE and ensure posture policy names match requirements
Packets do not appear in capturesThird-party firewall or endpoint local security is blocking posture trafficCheck local/third-party firewall rules, temporarily permit TCP/8443 for troubleshooting

Key Takeaways

  • AnyConnect posture (HostScan / compliance module) requires both ASA/FTD-side resources and ISE-side posture policies. Both sides must have compatible versions.
  • TCP/8443 connectivity is essential for posture report delivery to ISE PSNs — if this port is blocked, posture will remain pending.
  • Client provisioning ties the ASA profile, group-policy, and ISE configuration together — misalignment breaks posture delivery.
  • In production, treat posture as part of a larger health-check ecosystem: keep posture module databases up to date, maintain consistent AnyConnect package versions across ASA and ISE, and account for OS-specific behaviors (e.g., macOS utunX).

Important: Always review the detailed authentication report and ISE live logs when troubleshooting posture. Note the PSN that processed authentication, the authorization profile name, and any redirect attributes returned to the NAD. These details point directly to where in the posture chain problems occur.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security