Posture with VPN and MFA

Objective

In this lesson we integrate ISE posture with VPN connections and add Duo MFA (via a Duo Access Gateway / DAG SAML flow) so remote endpoints are posture-scanned and users complete multi-factor authentication before being allowed access. This matters because in production networks you must validate both the device compliance (posture) and the user identity (MFA) for remote access — protecting corporate resources even when users connect from unmanaged locations. A typical real-world scenario is a remote worker using AnyConnect to connect through a corporate ASA; the ASA delegates authentication to ISE (RADIUS) and delegates second-factor SSO to Duo (DAG via SAML), while ISE performs posture checks and returns an authorization profile.

Quick Recap

Refer to the topology created in Lesson 1. This lesson adds a Duo Access Gateway (DAG) for SAML MFA and highlights the ASA AnyConnect posture behavior. The original devices remain the same: ASA (ASA-1), ISE Primary (ISE-PSN), corporate switch (SW-1), and a remote client (AnyConnect). New device added:

Device	Hostname	Management / Relevant IP
Duo Access Gateway	DAG-1	198.51.100.10
ASA VPN	ASA-1	outside: 198.51.100.1 / inside: 10.1.1.1
ISE Posture PSN	ISE-PSN	10.1.2.10
Remote Client	Client-1	DHCP Any (AnyConnect virtual IP assigned)

ASCII topology (lab addresses shown):

[ Remote Client ] --- Internet --- [ ASA-1 outside 198.51.100.1 ] inside 10.1.1.1 --- [ SW-1 ] --- [ ISE-PSN 10.1.2.10 ]
                                                           \
                                                            \-- [ DAG-1 198.51.100.10 ]

Important: Domain names in examples use lab.nhprep.com. Use password Lab@123 for any GUI lab accounts created in the lab.

Key Concepts (Theory + Practical)

• Posture module flow (AnyConnect ↔ ISE):
  • When AnyConnect is configured for posture, the ASA can push posture resources (ISE Posture agent or posture profile) to the client during connection establishment. The client then contacts ISE (PSN) to perform a posture scan over HTTPS (typically TCP/8443). ISE evaluates posture and returns a compliance decision. In production this ensures endpoints meet security policies before granting access.
  • Protocol notes: posture scans commonly use HTTPS (TCP/8443). If the posture report cannot reach ISE (blocked by firewall), the posture state remains pending and the endpoint cannot progress to full access.
• MFA with Duo via SAML (ASA ←→ DAG):
  • ASA delegates SSO to a SAML Identity Provider (IdP). DAG (Duo Access Gateway) acts as the IdP that performs secondary authentication (Duo push). The ASA initiates SAML, the user receives a second-factor prompt, and the IdP returns a SAML assertion to the ASA.
  • Real-world: This enables ASA to keep using RADIUS for primary auth against ISE while still performing a seamless second-factor through Duo (no local ASA MFA plug-in required).
• Split-tunnel vs Tunnel-all behavior:
  • If the VPN is split-tunnel, posture traffic from the client might go directly to the Internet instead of through the tunnel — careful routing and firewall rules must ensure posture traffic reaches ISE (or posture will fail).
  • macOS clients using utunX interfaces may lack a default gateway on the VPN adapter — posture may require explicit routing or pushing DNS/GW via the connection.
• NAD and resource compatibility:
  • ASA/FTD can push posture resources (posture module, posture profile) to the client. It is critical that AnyConnect client versions on ASA and ISE align — mismatches often cause "Failed to launch downloader" or Agent update errors.
  • In production: keep AnyConnect images synchronized across ASA/FTD and ISE posture configuration, or use "defer update" carefully.

Step-by-step configuration

Step 1: Prepare ASA interfaces and basic AnyConnect webvpn

What we are doing: Configure ASA interface IPs, enable webvpn (AnyConnect), and ensure the ASA can serve AnyConnect images and posture resources. This step allows remote clients to reach the ASA and download posture resources during VPN establishment.

configure terminal
interface GigabitEthernet0/0
 nameif outside
 security-level 0
 ip address 198.51.100.1 255.255.255.0
 no shutdown
exit
interface GigabitEthernet0/1
 nameif inside
 security-level 100
 ip address 10.1.1.1 255.255.255.0
 no shutdown
exit

route outside 0.0.0.0 0.0.0.0 198.51.100.254

webvpn
 enable outside
 anyconnect image disk0:/anyconnect-win-4.10.03027-k9.pkg 1
 anyconnect image disk0:/anyconnect-macos-4.10.03027-k9.pkg 1
 anyconnect profile ANYCONNECT_PROFILE disk0:/anyconnect-profile.xml
 exit
write memory

What just happened:

• Interface commands set ASA outside/inside names and IP addresses so the ASA can terminate VPN connections and reach ISE and DAG. The default route points to the Internet gateway.
• webvpn commands enable AnyConnect on the outside interface and register AnyConnect images and a client profile that may include posture settings. ASA will serve these images to remote clients when they connect.

Real-world note: Serve AnyConnect images that match posture expectations on ISE. If versions differ, posture agent updates or launches may fail.

Verify:

show running-config interface GigabitEthernet0/0
! Expected output:
interface GigabitEthernet0/0
 nameif outside
 security-level 0
 ip address 198.51.100.1 255.255.255.0
!
show running-config webvpn
! Expected output includes:
webvpn
 enable outside
 anyconnect image disk0:/anyconnect-win-4.10.03027-k9.pkg 1
 anyconnect image disk0:/anyconnect-macos-4.10.03027-k9.pkg 1
 anyconnect profile ANYCONNECT_PROFILE disk0:/anyconnect-profile.xml

---

Step 2: Configure ASA to use SAML IdP (Duo DAG) for second-factor SSO

What we are doing: Configure ASA to delegate SAML authentication to the Duo Access Gateway (DAG-1 at 198.51.100.10). This enables ASA to redirect users to Duo for MFA during VPN login while using RADIUS/ISe for primary authentication.

configure terminal
webvpn
 saml idp https://198.51.100.10/saml
  idp-entity-id https://dag.lab.nhprep.com
  idp-signing-cert disk0:/dag-idp-cert.pem
 exit
exit
write memory

What just happened:

• The ASA webvpn SAML configuration registers the DAG as a SAML Identity Provider and sets the IdP entity ID and public certificate used to validate SAML responses. When ASA initiates SAML, it will redirect the client to the DAG for authentication and wait for the SAML assertion.

Real-world note: In production, DAG uses the enterprise IdP combining Duo push with existing credentials. Ensure time synchronization (NTP) and certificate validity — SAML fails with clock skew or invalid certs.

Verify:

show running-config webvpn
! Expected output shows saml idp config:
webvpn
 ...
 saml idp https://198.51.100.10/saml
  idp-entity-id https://dag.lab.nhprep.com
  idp-signing-cert disk0:/dag-idp-cert.pem

---

Step 3: Configure ASA to push posture resources (AnyConnect posture) to clients

What we are doing: Tell the ASA to make posture resources available and associate them with a group‑policy so clients receive the posture agent/profile during connection. Posture resources allow AnyConnect to start an ISE posture assessment.

configure terminal
group-policy NHPREP_VPN_POLICY internal
group-policy NHPREP_VPN_POLICY attributes
 vpn-tunnel-protocol ssl-client
 webvpn
  anyconnect profiles value ANYCONNECT_PROFILE type user
  anyconnect posture enable
 exit
exit

tunnel-group NHPREP_SSL type remote-access
tunnel-group NHPREP_SSL general-attributes
 default-group-policy NHPREP_VPN_POLICY
 exit
write memory

What just happened:

• A group-policy named NHPREP_VPN_POLICY was created and configured to allow SSL AnyConnect tunnels and to enable AnyConnect posture. Tunnnel-group NHPREP_SSL ties users to that policy by default.
• When clients connect to the tunnel-group, ASA will present the configured AnyConnect profile, and the posture section instructs the client to launch the posture module and connect to ISE for assessment.

Real-world note: On macOS, ensure the AnyConnect posture module is compatible with the utunX interface behavior — otherwise posture traffic may be misrouted.

Verify:

show running-config group-policy NHPREP_VPN_POLICY
! Expected output includes:
group-policy NHPREP_VPN_POLICY internal
group-policy NHPREP_VPN_POLICY attributes
 vpn-tunnel-protocol ssl-client
 webvpn
  anyconnect profiles value ANYCONNECT_PROFILE type user
  anyconnect posture enable

show running-config tunnel-group NHPREP_SSL
! Expected output includes:
tunnel-group NHPREP_SSL type remote-access
tunnel-group NHPREP_SSL general-attributes
 default-group-policy NHPREP_VPN_POLICY

---

Step 4: Configure ISE for posture and RADIUS authentication (PSN reachability and posture ports)

What we are doing: Ensure ISE (ISE-PSN at 10.1.2.10) is reachable from ASA, that posture services listen on the correct ports (notably TCP/8443), and that ASA is configured as a RADIUS client in ISE. This enables posture scans and auth flow.

! This is an illustration of the conceptual steps performed in ISE GUI.
! On ASA make sure RADIUS server for authentication is pointed to ISE:
configure terminal
aaa-server ISE_SERVERS protocol radius
aaa-server ISE_SERVERS (inside) host 10.1.2.10
 key Lab@123
exit
write memory

What just happened:

• ASA now knows ISE as the RADIUS server (ISE_SERVERS) reachable on 10.1.2.10. ASA will send RADIUS Access-Request messages for authentication and accounting to ISE.
• ISE must have posture services active on the PSN handling the request. Posture scans use HTTPS on TCP/8443. If packets are blocked by network or third-party firewall, ISE will remain in a pending posture state.

Real-world note: If posture scans show "Pending" in ISE, confirm path connectivity to TCP/8443 and that any middlebox (NGFW) isn't blocking or altering traffic.

Verify:

show aaa-server RADIUS ISE_SERVERS
! Expected output:
RADIUS server group ISE_SERVERS
  Server: 10.1.2.10, key: configured, protocol: RADIUS
  Interface: inside

! From a network perspective, test TCP/8443 from ASA to ISE (use ASA's ping/tcp-check facility, simulated here):
telnet 10.1.2.10 8443
! Expected result: Connection opens; if rejected, posture will fail.

---

Step 5: End-to-end test — AnyConnect VPN + SAML MFA + Posture scan

What we are doing: Perform a real connection from the remote client. The client will download AnyConnect, initiate SAML redirect to DAG for Duo push, complete primary auth via ISE RADIUS, and run posture checks against ISE over TCP/8443. This is the full validation step.

! On ASA, monitor active AnyConnect sessions and posture interactions:
show vpn-sessiondb anyconnect
! Expected output (sample):
Session Type: AnyConnect
Username      : nhprepuser
Index         : 1
Peer IP       : 203.0.113.55
Assigned IP   : 10.10.10.50
Group Policy  : NHPREP_VPN_POLICY
Posture State : POSTURE-PENDING/COMPLIANT

! Monitor webvpn SAML state if supported:
show webvpn saml
! Expected output should show recent SAML requests/responses and IdP URL https://198.51.100.10/saml

What just happened:

• show vpn-sessiondb anyconnect lists the active AnyConnect session, assigned IP, and posture state. If posture is COMPLIANT, endpoint met ISE posture requirements and will receive the authorized network access based on the ISE authorization profile. If POSTURE-PENDING, the posture scan hasn't completed or failed.

Real-world note: If you see "POSTURE-PENDING" and no posture reports in ISE, collect packet captures and check for connectivity to TCP/8443; also retrieve DART logs from the AnyConnect client for detailed client-side errors.

Verify (on ISE):

! On ISE GUI you would check Live Logs and Posture Assessment Report for the endpoint.
! CLI-style verification (conceptual):
show application ise posture report mac <client-mac>
! Expected conceptual output:
Posture Report for MAC <client-mac>
 Last scan: 2026-04-02 10:15:23
 Posture Decision: COMPLIANT
 PSN: 10.1.2.10
 Matched Posture Policy: VPN-Endpoint-Policy
Requirements:
 - AV present: PASSED
 - Firewall enabled: PASSED
 - Patch Level: PASSED

Verification Checklist

• Check 1: ASA outside (198.51.100.1) and inside (10.1.1.1) interfaces are up — verify with show interface ip brief and confirm addresses match.
• Check 2: AnyConnect images and profile are present on ASA — verify with show running-config webvpn and confirm anyconnect image and anyconnect profile entries.
• Check 3: ASA has ISE configured as RADIUS server — verify with show aaa-server RADIUS ISE_SERVERS and confirm host 10.1.2.10 and key Lab@123.
• Check 4: Posture traffic can reach ISE PSN on TCP/8443 — verify by initiating posture scan or testing reachability (telnet 10.1.2.10 8443 from ASA or performing client-side DART logs).
• Check 5: SAML IdP is configured and reachable (https://198.51.100.10/saml) — verify via show running-config webvpn and test SAML login end-to-end (client login results in Duo push).

Common Mistakes

Symptom	Cause	Fix
Posture state remains "PENDING" in ISE	ASA or intermediate firewall blocking TCP/8443 from client to ISE	Open/allow TCP/8443 between client (or ASA if posture proxied) and ISE PSN; check NGFW rules
AnyConnect posture module fails to launch with "Failed to Launch Downloader"	AnyConnect image or posture resource mismatch between ASA and ISE, or agent version incompatibility	Ensure AnyConnect package versions on ASA and ISE are identical; use "defer update" only as a controlled option
SAML authentication fails or user never receives Duo push	Invalid IdP signing certificate, wrong IdP entity ID, or time skew	Verify DAG certificate is uploaded to ASA, entity ID matches, and NTP is correct on ASA and DAG
macOS client posture fails intermittently	macOS utunX interface has no default gateway and posture traffic is split-tunnel	Configure split-tunnel exceptions or enable tunnel-all for posture traffic; ensure AnyConnect profile pushes required routes
No posture reports visible in ISE	PSN that handled authentication is not the one performing posture, or packets aren't reaching PSN	Check which PSN performed auth in Live Logs; collect packet capture between ASA and ISE PSN; ensure DACL/ACLs allow posture flows

Key Takeaways

• Posture over VPN requires three things to align: ASA/FTD posture/resource push, reachable ISE posture service (TCP/8443), and a compatible AnyConnect posture module/version.
• Duo MFA (via DAG SAML) can be integrated with ASA to provide second-factor authentication while RADIUS/ISe continues to perform primary auth and posture decisions.
• In production, always validate path connectivity (firewall rules, NGFW policies) for posture ports early — many posture failures are due to blocked ports (8443 / 8449 mentioned in posture components).
• Collect comprehensive telemetry for troubleshooting: AnyConnect DART logs, ISE Live Logs, posture assessment reports, RADIUS authentication/accounting details, and packet captures showing TCP/8443 traffic.

Tip: When troubleshooting posture failures, start by confirming which PSN handled the authentication (Live Logs -> Authentication details) and then check that PSN's ability to receive posture connections and generate Posture Assessment Reports. If posture traffic is absent at the switch, confirm firewall/NGFW rules especially on ports TCP/8443 and TCP/8449 depending on your posture components.

This lesson demonstrated end-to-end posture + VPN + Duo MFA integration and highlighted the important operational checks and pitfalls you will see in production. In the next lesson we will cover advanced troubleshooting and deep-dive into posture reports and DART analysis.