cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3111
Views
5
Helpful
5
Replies

ISE a different PSN is responing CoA

josgarza
Level 1
Level 1

hi Experts,

I already have a SR opened for this issue (682932824) but wanted to touch base with you and see if you have seen this behavior before.

We are running an ISE 2.1 patch 4 deployment and currently focused on VPN authentication with posture.

The following issue is randomly happening and I think I found the cause:

Sometimes, the user connects to the VPN, AnyConnect starts the posture process and finish giving the message "Compliant" to the device. However, the device stills stuck at the Posture redirection phase. The CoA was not applied to the ASA in order to change the authentication and the message "Dynamic Authorization failed" is shown in the ISE logs.

What I've found looking at the logs in ISE, is that when the message "Dynamic Authorization failed" shows, the PSN server is different than the one that is taking care of the radius authentication.

For successful CoA flows, the PSN server is always the same.

As a note, there's a F5 Load balancer in front of the PSN server.

However, the CoA message should be originated from the Server that is owning the radius session, right? So, I don't see how the F5 could be impacting this.

Any Ideas?

1 Accepted Solution

Accepted Solutions

Please follow the guidelines in the F5 ISE LB Guide posted here: ISE Load Balancing

It provides guidance on maintaining persistence between RADIUS auth and accounting, as well as using SNAT for CoA packets so they originate from same IP used for RADIUS (the F5 virtual IP).

Craig

View solution in original post

5 Replies 5

hslai
Cisco Employee
Cisco Employee

Please run RADIUS accounting reports and verify that the PSN receiving the accounting request is the same performing the auth requests. Also, ensure the accounting mode in ASA is configured for single, especially if more than one RADIUS server configured.

hi Hsing-Tsu,

So I validated that the accounting server is different than the authentication server. However, the same happens for working and non-working scenarios. Why sometimes works and sometimes doesn't?

Obviously, this now points to be a problem on the F5 and the sticky feature.

When auth and accounting requests sending to different PSNs, it can be problematic as you are observing -- sometime it works but sometime it fails. Please update the F5 rule(s) so the auth and accounting for the same session are going to the same PSN.

Please follow the guidelines in the F5 ISE LB Guide posted here: ISE Load Balancing

It provides guidance on maintaining persistence between RADIUS auth and accounting, as well as using SNAT for CoA packets so they originate from same IP used for RADIUS (the F5 virtual IP).

Craig

How are you doing posture discovery?  Did you validate the posture report is being submitted to the same PSN that authenticated it?