ISE CoA with ASA action not supported

[DAVIES604]

Hi All,

 Apologies if this is in the wrong area, but it covers a few.

I'm setting up RA VPN using Anyconnect client 4.6, ASA headends are 5545's running 9.9. I am also integrating ISE 2.4.
The clients currently authenticate via certificate on the ASA, then with AD credentials via ISE, this all seems to work nicely. The problem comes when I try to set up posturing/compliance, I can get the posturing module to find the policy server, and redirect url for provisioning works, and also DACL is enforced whilst client is in an 'unknown compliance' authorisation profile. However when the client finishes successful compliancy scan and sends result to ISE, the ISE then sends a CoA request to the ASA for that particular session, as expected, but the ASA logs 'CoA (Action type 43) from 'ISE server ip' failed for user 'username', with session ID 'session id'. Action not supported.

 Wireshark shows it sending AVP subscriber:command=reauthentcicate, and coa-push+true amongst others.

 The Cisco docs say the log means the packet is correctly formed but the action is unsupported, I'm using the default Cisco device profile on ISE with CoA settings. If I send a CoA terminate session request from ISE, it is successful.

 I'm struggling to find any similar problem online and I don't have much experience with CoA, so I'm thinking I've maybe set something up wrong.

 Anyone got any ideas? Would be greatly appreciated.

[misinsuan2229]

Have you configured your aaa-server config  to have dynamic-authorization? This will make the the ASA to accept CoA

[DAVIES604]

Thanks for the reply, yes dynamic authorization is configured in the AAA server group

[Surendra]

Can you send us the tunnel group and the general AAA configuration you have done for this VPN connection?

[DAVIES604]

Hi Surendra,

Thanks for the reply, I will get the config for you. Just want to add something I've noticed first that doesn't seem right to me, but not sure.

In the ISE Dynamic Authorization failed log, the Endpoint Id and the Calling station Id is the IP address of the end client, not the vpn pool address, but the devices local address. In the other auth/session log entries the Endpoint Id is the MAC address, is this part of the problem? Thanks.

[DAVIES604]

Hi Surendra,

Here's the AAA and Tunnel group config.

AAA:

aaa-server AUTH_SERVER_GROUP protocol radius
 interim-accounting-update periodic 24
 dynamic-authorization
aaa-server AUTH_SERVER_GROUP (management) host a.b.c.d
 key *****
aaa-server AUTH_SERVER_GROUP (management) host a.b.c.e
 key *****

Tunnel Group:

tunnel-group TEST_GROUP type remote-access
tunnel-group TEST_GROUP general-attributes
 address-pool anyconnect_clients
 authentication-server-group AUTH_SERVER_GROUP LOCAL
 authorization-server-group AUTH_SERVER_GROUP
 accounting-server-group AUTH_SERVER_GROUP
 default-group-policy TEST_POLICY
tunnel-group TEST_GROUP webvpn-attributes
 authentication aaa certificate
 group-alias TEST_GROUP enable
 group-url https://test.com enable
 group-url https://test1.com enable
 without-csd

Thanks.

[Surendra · Accepted solution]

Can you please remove this command “authorization-server-group AUTH_SERVER_GROUP” because both authorization and authentication happen at the same time and this might cause duplicate requests and session-IDs to be generated on the ISE?

Cheers.

[DAVIES604]

Brilliant, that worked, CoA is now working. That also explained a few extra log entries I was getting. Thank you.

I'm not sure if my set up is correct though, the Endpoint Id for the CoA log is still the client IP, the live session page shows the MAC for endpoint, and says Authorization profile is my non-compliant one. The log for the CoA shows my compliant profile but IP address. Shouldn't the session details update? Also there is less information on the dashboard now, identity stores, active endpoints are blank. It still seems like I've not set something up quite right.

[Surendra]

It could be because of the bugs CSCuy67881 and CSCuy67926 that you are not seeing any updates to the live sessions and dashboards. If the conditions do not meet, suggest you to open a case with TAC.

[DAVIES604]

I'll have a look at these. Many thanks for your help.

[Sri Harsha Dasari]

You have to ISE Server Group on Account to get the live sessions counts accurate

[DAVIES604]

Hi,

Just wanted to add.

The client also never uses an Apex license, even when it falls into an authorization profile with posturing, which I thought was expected behaviour.

Also, should I mark this as accepted solution to the original issue?

[TERRY GRACE]

I'm having the same issue with posture on an ASA and ISE 2.3P7. Live Sessions log shows compliant but preposture acl in effect. ASA shows compliant ACL applied to vpn session. Live Logs show initial auth ok, coa works but no userid in coa log entry or subsequent acl being applied log entry. Like you, initial auth shows mac address then subsequent log entries show client public ip. No Alex licenses being consumed either.

Was there a fix to your issue? 

[Nidhi]

This is an expected behavior and documented here - https://www.cisco.com/c/en/us/support/docs/security/adaptive-security-appliance-asa-software/117693-configure-ASA-00.html 

[DAVIES604]

Hi,

Unfortunately I still have these issues, and I'm currently on the latest patch of the recommended version.

Everything actually functions as required in terms of the client posturing and acl's being applied, so the problems do seem to be cosmetic. We still haven't really decided to utilise posturing fully yet, so it's not a huge issue for us at the moment, but if we do I could see this as a pretty annoying issue, as you can't rely on what the logs are showing. The session logs status's don't always get updated, so most of them say 'Started' a handful will say 'Postured' but all will have posture status as 'Compliant'.

I think I read somewhere when trying to get to the bottom of this, that when using this combination of ISE posture with Remote Access VPN and ASA's, it will always use the client endpoint local IP as the Endpoint ID in the logs for CoA, it's not a fault, but a limitation of that setup, this may be the root of the all the 'cosmetic' problems. We don't have any posturing set up on the LAN or any other type of RA VPN headends, so don't have anything to compare with. Would be nice to get that confirmed. I have never managed to get it to show any used Apex licences.

Sorry that's not much help, it's something we just live with at the moment.

Do you have posturing on LAN clients?