Issue
The reported issue can present as the endpoint remaining in an "Unknown" posture compliance status. Additionally, the Posture Provisioning Portal can not be displayed to the user.
In some scenarios, customers have reported that after migrating from ASA to FTD, they reused the same configuration; however, FTD requires additional and specific settings for Posture VPN to function correctly.
Environment
- Cisco Identity Services Engine (ISE) version 3.3
- ISE deployment with two nodes
- Cisco Secure Client version 5.1.7.80
- Firepower Threat Defense (FTD) version 7.4.1.1
- Endpoints connecting via VPN
- Relevant IP address for posture validation: 72.163.1.80 (enroll.cisco.com)
Resolution
These steps detail the workflow for identifying, diagnosing, and resolving the ISE posture validation issue after migration to FTD. Each step is explained for clarity, with direct references to logs and configuration indicators as observed in the environment.
Step 1: Collect a DART Bundle to Verify Probes
Check the posture status of endpoints attempting VPN connectivity for any errors or stuck states. Review the ISE posture agent logs (ISEPosture.txt) for error messages indicating invalid server servers or not rechable status.
Example log excerpt indicating the issue:
2026/01/05 15:38:26 [Warning] csc_iseagent Function: Target::parsePostureStatusResponse Thread Id: 0x32D0 File: Target.cpp Line: 370 Level: warn Headend is empty. Possibly, content is not in the form 'X-ISE-PDP'..
2026/01/05 15:38:26 [Information] csc_iseagent Function: Target::Probe Thread Id: 0x32D0 File: Target.cpp Line: 212 Level: debug Status of Redirection target 192.168.1.254 is 5 <Invalid server.>.
2026/01/05 15:38:28 [Information] csc_iseagent Function: SwiftHttpRunner::http_discovery_callback Thread Id: 0x1AD8 File: SwiftHttpRunner.cpp Line: 519 Level: info Time out for Redirection target enroll.cisco.com.
2026/01/05 15:38:28 [Information] csc_iseagent Function: SwiftHttpRunner::http_discovery_callback Thread Id: 0x1AD8 File: SwiftHttpRunner.cpp Line: 580 Level: info Enabling next round timer.
2026/01/05 15:38:28 [Information] csc_iseagent Function: GetCurrentUserName Thread Id: 0x1AD8 File: ImpersonateUser.cpp Line: 60 Level: info Username of the currently logged in user is basheer.mohamed.
2026/01/05 15:38:29 [Information] csc_iseagent Function: hs_transport_winhttp_get Thread Id: 0x698C File: hs_transport_winhttp.c Line: 4912 Level: debug The request has timed out..
2026/01/05 15:38:29 [Information] csc_iseagent Function: Target::probeDiscoveryUrl Thread Id: 0x698C File: Target.cpp Line: 269 Level: debug GET request to URL (http://enroll.cisco.com/auth/discovery?architecture=9), returned status -1 <Operation Failed.>.
2026/01/05 15:38:29 [Information] csc_iseagent Function: Target::Probe Thread Id: 0x698C File: Target.cpp Line: 212 Level: debug Status of Redirection target enroll.cisco.com is 6 <Not Reachable.>.
In this case, enroll.cisco.com is not reachable, which causes the discovery process to fail.
Step 2: Confirm ISE Authorization Profile and Live Logs
Verify that the RADIUS livelog is correctly pushed to the endpoint. It must include Access Accept and URL redirect parameters for posture validation.
Example:
Access Type = ACCESS_ACCEPT
cisco-av-pair = url-redirect-acl=redirect
cisco-av-pair = url-redirect=https://ip:port/portal/gateway?sessionId=SessionIdValue&portal=4cb1f740-e371-11e6-92ce-005056873bd0&action=cpp
For this specific example, we have confirmed that the redirection is working as expected; however, the discovery process fails because the gateway is reported as an invalid server. This behavior can be expected in a VPN integration scenario, as the endpoint does not rely on the VPN gateway for discovery. Instead, the endpoint attempts to reach the ISE node using enroll.cisco.com.
Step 3. Verify the ACLs Settings in the FTD
Verify that enroll.cisco.com is explicitly permitted in the redirection ACL as well as in the ACL configured for the Split Tunnel.
To check both ACLs, in the FMC you can navigate toObject > Object Management > Access List > Extended.
To check if Split Tunnel is configured in the VPN, navigate to Devices > VPN > Remote Access > Choose the VPN and Connection Profile settings > Edit Group Policy > Split Tunnel.
Note: If Split Tunnel is not configured on the VPN policy, this validation is not required, hence the Split Tunnel ACL is not needed in this scenario.
Cause
The root cause of the issue was the absence of the required discovery IP address (72.163.1.80, enroll.cisco.com) in the network policy after migration to Firepower Threat Defense (FTD).
Without this IP, Cisco Secure Client was unable to discover the ISE Policy Service Node when connecting over VPN, resulting in posture status remaining in a pending state. Additionally, disabled location services on endpoints contributed to incomplete posture validation.
Related Content
Feedback