on the IC you configure a max session length at the role level.
A client using the oac agent will have a https-control session towards the IC.
When the max session timeout is reached the client (and IC/UAC) will not only close the https-session but the client will also send a EAPoL-Logoff message to the switch.
This leads to a complete interface interruption and a new authentication is started.
This is very bad because the client will terminate all running tcp sessions. For example a rdp-session gets disrupted. The disruption occurs for approximately 15 seconds.
To circumvent this Juniper mentions in the admin guide for the IC/UAC a "use case 5" where the problem is described and where the solution is mentioned, that the switch should use a shorter timeout value for the 802.1x session than the "max session timeout" for the IC/UAC session.
This can be done by sending a shorter Session-Timeout Radius return attribute from the IC/UAC towards the switch or by configuring a hard reauthentication timer on the switch.
Juniper mentions: "When the switch or wireless access point times out a session, the Odyssey Access Client can resume the Infranet Controller session by interacting with the Infranet Controller without interrupting network access. There are two ways that this can be done on the Odyssey Access Client:
´ TTLS session resumptionOdyssey Access Client reauthenticates to the Infranet Controller based on TLS keying material from the previous session.
´ DSID session resumptionthis happens when TTLS session resumption fails but the Infranet Controller session is still valid. TTLS session resumption can fail if Odyssey Access Client is configured for a shorter TTLS session resumption maximum than the length of the IC session. In DSID session resumption, Odyssey Access Client authenticates to the Infranet Controller using new TLS keying material, but without creating a new IC session. You configure Session Resumption on the Odyssey Access Client Tools > Options panel."
BUT this does not work!
In fact it works only when I have a max session timeout value on the IC-role which is not longer than 10 minutes.
In this case a reauthentication - for example made by the switch - leads the oac agent to disconnect the session towards the IC and to build up of a new one. Only then the counter the counter of max session is reset.
When the max session timeout of the role is longer, the reauthentication takes place at the layer 2-level but the session between the client and the IC/UAC gets not renewed: The max session timer keeps counting down towards Zero. If zero is reached, the session is totally disconnected - also on layer 2. All TCP-sessions fail et cetera.
Can anyone explain to me the details of this behaviour?
I want to have a max session length of around 10 hours but no disconnection of the client.
Can you enable the option automatic reauthentication with every 2 hours value in OAC side and with Max. Session Length: 600 minutes at role level. This will hep your session to be active.
thank you for your proposal. But why do you think that this will solve the problem?
Where is the important difference between having 1 hours or 2 hours configured on the client?
Thank you for your answer,