Hi Alan, Thank you very much for all your help on this. I got in touch with the NAS makers (StrongSwan) and did some analysis together. Essentially the NAS only needs the User-Name for the disconnect request, which I'm already providing. The reason why it sends a NAK is that no IKE_SA was found with a matching remote identity. This is what happens on the NAS side in the log file:
received RADIUS DAE Disconnect-Request for houman from 127.0.0.1 no IKE_SA matches houman, sending Disconnect-NAK
So the question is why the disconnect fails upon login, but a bit later on it works again: "You can't use this method for IKE_SAs that are concurrently being established. Such IKE_SAs are locked and, thus, skipped by the Disconnect handler. This particular IKE_SA is waiting for the EAP-Accounting response and until that's received and the IKE_AUTH response has been sent, the IKE_SA can't be closed via this code path. It also affects SAs later if they are locked for some reason (e.g. handling rekeyings or DPDs, but not interim Accounting updates as the SA is unlocked before sending those). So perhaps the RADIUS server could retry sending the Disconnect message if it still has state around for the user but received a NAK (or delay sending the Disconnect for a bit)." It's a bit of a dilemma. I have a reason to disconnect the user based on a condition. But the user can still reconnect and I won't be able to disconnect him straight away. I have to wait until the next Acct-Interim-Interval kicks in before I can actually disconnect him again. Since the authentication happens through Freeradius, is there a way to reject the user immediately during authentication other than sending disconnect requests? Many Thanks, Houman On Tue, 15 Oct 2019 at 04:24, Alan DeKok <aland@deployingradius.com> wrote:
On Oct 14, 2019, at 4:03 PM, Houman <houmie@gmail.com> wrote:
There are only two issues, I wanted to discuss here with the group:
1) Is there a way to send a custom message to the NAS when a disconnect based on the custom condition happens? This way the user is not wondering why he keeps getting disconnected but gets to know the real reason behind it.
No. There is no ability in RADIUS to send custom messages in a Disconnect-Request packet. Even if there was, the underlying protocols (PPP, EAP, etc.) usually don't provide for messages on disconnect.
2) Even though I have added the condition to "authorize", "accounting" and "preacct" sections, the initial disconnect attempt remains unresponsive.
Read the debug log to see why.
(11) Sent Disconnect-Request Id 221 from 0.0.0.0:48470 to 127.0.0.1:3799 length 28 (11) User-Name = "houman" ... (11) Received Disconnect-NAK Id 221 from 127.0.0.1:3799 to 127.0.0.1:48470 length 20
The NAS sent a NAK. Which meant that the NAS refused to disconnect the user. Very likely because the attributes in the Disconnect-Request packet were not enough to identify the users session.
What attributes *should* be in the Disconnect-Request? The short answer is to read the NAS documentation. Generally the best guess is the same session attributes which are in the Accounting-Request packets.
Only after the 300 seconds pass (which is defined in Acct-Interim-Interval) the second disconnect attempt successfully disconnects the user.
No.
(13) Sent Disconnect-Request Id 103 from 0.0.0.0:48470 to 127.0.0.1:3799 length 28 (13) User-Name = "houman" ... (13) Received Disconnect-NAK Id 103 from 127.0.0.1:3799 to 127.0.0.1:48470 length 20
The NAS sends a NAK again.
The user might be disconnected at that time, but it has nothing to do with the Disconnect-Request packet that was sent.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html