Cisco ISE Posture Flow with VIP FQDN - Session Break Between PSNs?

[poornakumar]

Hi all, I have a Cisco ISE deployment with 6 PSNs load balanced using Radware. The VIP is configured for 3(1pan+mnt 2psn)+3(1pan+mnt 2psn) nodes, meaning there are two VIPs handling two PSNs each. For posture redirection, I'm using the redirectionless flow and in the postureCFG.xml, the Call-Home URL points to the VIP FQDN (e.g., https://ise-posture.company.com), as per our security policy.

Here’s my concern:

During RADIUS authentication, the client might hit PSN-1.

But the posture module (AnyConnect) will connect to the VIP FQDN, which Radware might resolve to PSN-2 due to load balancing.

As a result, the posture session may fail because PSN-2 has no session info for that client — leading to posture status as “unknown” or failure.

My questions:

1. Is there any way in ISE to make posture session information shared across PSNs (like through Node Groups)?

2. Does Node Group help in this specific scenario of posture flow?

3. What are the best practices for handling posture over VIPs while maintaining session consistency? Is sticky session the only way?

4. If sticky session is the way to go, what are the preferred methods — source IP, SSL session ID, or something else?

5. Are there any alternate ISE configurations (like smart call-home routing or posture broker) that can avoid this issue?

I need to use VIP FQDN mandatorily for posture for security reasons, so redirecting to individual PSNs is not an option.

Thanks in advance!

NOTE:TAC CASE is already raised.

[ahollifield]

You need to configure your load-balancer for persistence to ensure the posture flow hits the same PSN as the RADIUS flow.

1. No but what version of ISE? 3.4 has made some major enhancements to endpoint ownership.
2. No
3. Sticky session/persistence.
4. MAC address
5. No, but why not just let the posture flow hit the PSN directly? Why force that through the VIP at all? "

   I need to use VIP FQDN mandatorily for posture for security reasons, so redirecting to individual PSNs is not an option." Why? What is gained here?

[poornakumar]

As per the client's internal audit requirements, exposing direct PSN IPs during posture redirection is considered a security risk. It could potentially lead to targeted attacks such as DDoS. Therefore, the use of a VIP FQDN is mandated to ensure backend PSNs remain hidden and protected. 

[ahollifield]

But why? Is the load balancer providing some sort of DDoS prevention? Couldn’t an attacker just DDoS the load balancer bringing the entire deployment down?

Wouldn’t this type of attack also require the device to already have valid network access via 802.1X?

[poornakumar]

Yup I completely agree with your point but we won't expect the attack will happen from an external source right may be internal attack also possible. So if we configure VIP might be a extra layer of protection and also we can manage DDos if it is VIP configured one compared with real PSN ip exposed. Load balancing, rate limiting these options we can done centrally right and also I know I'm going into some unimaginable situation but auditing team can go in this way only.