Security

I am seeing, when a client is disconnected but there is no Accounting Stop packet (e.g. the switch or AP lost power, or the client disconnected while ClearPass was rebooting, or for any other reason the Stop packet was not received) - the session can stay active for days, still appearing under Active Sessions in Access Tracker, and the session on our FortiGate (which receives data from ClearPass's Accounting Proxy) is still listed as well.

If we are sending Accounting interim packets every hour, it would make sense to consider any accounting session where ClearPass has not received an interim in 3 hours to be closed.  Is there any way to configure a timeout like this?

We currently have our accounting interim interval configured on our switches and APs, not sent in the RADIUS Access-Accept.  If we added the IETF Acct-Interim-Interval in the enforcement profile, would that cause ClearPass to "expect" the interim packets (and thus, drop sessions that are stale and not receiving interims)?  If not, then what about if we added the Session-Timeout and Termination-Action to require re-authentication every couple of hours?

Ultimately, what I want is a way to make ClearPass to "expect" the interim accounting updates, and realize that sessions are stale if they are not coming in, so a missed stop packet does not result in a session that stays open indefinitely.

I waited for a while before responding, as I don't know the answer to this question.

It may be a good one for TAC if there are no others that know the answer. Haven't heard this before, also think it's quite rare/exceptional in practice that switches reboot or ClearPass reboots (all nodes in a cluster). If the feature to report sessions active based on ongoing accounting may be requested through the Innovation Zone (check with your partner or local HPE Aruba Networking SE for more info).

I am seeing, when a client is disconnected but there is no Accounting Stop packet (e.g. the switch or AP lost power, or the client disconnected while ClearPass was rebooting, or for any other reason the Stop packet was not received) - the session can stay active for days, still appearing under Active Sessions in Access Tracker, and the session on our FortiGate (which receives data from ClearPass's Accounting Proxy) is still listed as well.

If we are sending Accounting interim packets every hour, it would make sense to consider any accounting session where ClearPass has not received an interim in 3 hours to be closed.  Is there any way to configure a timeout like this?

We currently have our accounting interim interval configured on our switches and APs, not sent in the RADIUS Access-Accept.  If we added the IETF Acct-Interim-Interval in the enforcement profile, would that cause ClearPass to "expect" the interim packets (and thus, drop sessions that are stale and not receiving interims)?  If not, then what about if we added the Session-Timeout and Termination-Action to require re-authentication every couple of hours?

Ultimately, what I want is a way to make ClearPass to "expect" the interim accounting updates, and realize that sessions are stale if they are not coming in, so a missed stop packet does not result in a session that stays open indefinitely.

I have a similar situation, but more self induced.  We have long sessions, actually no session-timeout, but rather the device/port is given an idle timeout.  In this case the devices will maintain active accounting sessions, but the session "state" will show "stale" via the API/json, and I lose the ability to issue a CoA (port bounce), etc... at that point.  I'm not sure at what point the session goes "stale".  This was done to avoid a reauth or session timeouts from affecting a clients activity/established sockets.  This may be a misunderstanding on my part, but I thought that's what I was seeing occur, and thus was trying to avoid.

I waited for a while before responding, as I don't know the answer to this question.

It may be a good one for TAC if there are no others that know the answer. Haven't heard this before, also think it's quite rare/exceptional in practice that switches reboot or ClearPass reboots (all nodes in a cluster). If the feature to report sessions active based on ongoing accounting may be requested through the Innovation Zone (check with your partner or local HPE Aruba Networking SE for more info).

I am seeing, when a client is disconnected but there is no Accounting Stop packet (e.g. the switch or AP lost power, or the client disconnected while ClearPass was rebooting, or for any other reason the Stop packet was not received) - the session can stay active for days, still appearing under Active Sessions in Access Tracker, and the session on our FortiGate (which receives data from ClearPass's Accounting Proxy) is still listed as well.

If we are sending Accounting interim packets every hour, it would make sense to consider any accounting session where ClearPass has not received an interim in 3 hours to be closed.  Is there any way to configure a timeout like this?

We currently have our accounting interim interval configured on our switches and APs, not sent in the RADIUS Access-Accept.  If we added the IETF Acct-Interim-Interval in the enforcement profile, would that cause ClearPass to "expect" the interim packets (and thus, drop sessions that are stale and not receiving interims)?  If not, then what about if we added the Session-Timeout and Termination-Action to require re-authentication every couple of hours?

Ultimately, what I want is a way to make ClearPass to "expect" the interim accounting updates, and realize that sessions are stale if they are not coming in, so a missed stop packet does not result in a session that stays open indefinitely.