I'm working on a solution that includes RADIUS-backed DHCP as a component. Unfortunately, the DHCP server in ROS seems to have a behavior that works counter to the goal of this design. In a nutshell, whenever I enable RADIUS on the server, the server will send RADIUS authentication requests for new clients, but if an existing client renews its lease, the server just ACK's the renewal and refreshes the lease time without asking the RADIUS server.

This is a problem because what if we were to disable a customer in RADIUS? The server would continue to allow the client to remain on the network indefinitely w/o some form of administrative intervention such as deleting the lease, shutting down their physical access port/device, etc. The goal is to completely govern the routine user administration via profiles in a RADIUS database so that 1st tier tech support personnel can easily do the majority of the basic stuff. . .

Is there a workaround for this that I'm just not seeing? Sometimes there's an interesting setting that I've just never considered or noticed in the docs (such as using relay=255.255.255.255 to accept any relay as a client).

I'm sorry I've no answers, but I have a question:

the lease duration is set by MT dhcp server (settings) or by Radius?

I guess deleting leases via script lead to a overlapping addresses risk (can radius take care of this?)

I'm sorry I've no answers, but I have a question:

the lease duration is set by MT dhcp server (settings) or by Radius?

I guess deleting leases via script lead to a overlapping addresses risk (can radius take care of this?)

Mikrotik uses the DHCP server configuration for lease time unless specified by the RADIUS server (as Session-Timeout={n-seconds}).
The real issue is that I've noticed in the field where I'm playing around with some of this, the various customers' routers tend to renew at unpredictable time periods. The general standard is to start renewing at 1/2 lease time, but I've seen some of them wait until nearly the end of the lease. In whatever case, if I use lease->arp entry creation to enforce DHCP use, I cannot delete leases at any time prior to their actual expiration because it will break connectivity for the user.

I found an article where Mikrotik supports RADIUS packet of disconnect, but I haven't tested it yet. I think this would be more useful in a PPPoE situiation because at least the client would immediately know that it had been disconnected, whereas simply ripping a lease out from under them would not give any indication as to why things stopped working.

.. if I use lease->arp entry creation to enforce DHCP use, I cannot delete leases at any time prior to their actual expiration because it will break connectivity for the user.
.. would not give any indication as to why things stopped working.

I see, in this scenario neither CoA (if supported in dhcp) will help you.
Maybe you can tweak radius to assign a "please_pay-ip_pool" network ip (& arp) to disabled users by which customers can have some advice ..?

ZeroByte, what version of RouterOS are you testing with?

We reported this exact issue as a bug and worked with Mikrotik support to fix it recently.

It is resolved in newer releases. 6.39 and newer...

We reported this exact issue as a bug and worked with Mikrotik support to fix it recently.

It is resolved in newer releases. 6.39 and newer...

lol - I have two different versions running in my GNS3 testbed, one is 6.41rc66, and the other is 6.38.5
The 6.38 was the first one I put into the test topology and was the one I noticed this issue on. I swung DHCP over to the one running 6.41rc66 and it's apparently working properly. Thanks for the heads-up on this fix!

Interestingly, it was the new RADIUS accounting on DHCP that had me put rc66 in the lab, but I didn't scrutinize the authentication process on that one.

It is resolved in newer releases. 6.39 and newer...

Apparently I spoke too soon. I had the logging level set too low on my router and saw the RADIUS traffic corresponding with lease renewals. I thought these were AUTH requests/replies, but upon deeper inspection, it appears that this was just RADIUS accounting packets. I'm not seeing any RADIUS auth requests/responses for renewals of existing leases at the Mikrotik.

Here's my configuration: (version = 6.41rc66) For the sake of complete disclosure - the DHCP client in this test bed is the GNS3 VPC host, which is very basic in nature.

Observations from packet captures:
The initial DHCP process works as anyone might expect. Client sends a DHCP discover, which causes the Mikrotik to send a RADIUS auth request. If accepted, the Mikrotik creates a lease and offers it to the client, the client then requests the address and is ACK'd by the router, leading to a RADIUS accounting start.

If the client renews its lease by skipping the DHCP discover - i.e. it just requests its IP address again - the Mikrotik ACKs this without any activity in RADIUS either auth or accounting.

If the client renews its lease by sending a discover request, then the Mikrotik sends an accounting stop record to RADIUS, followed by the offer -> direct request -> ACK process. When the Mikrotik sends the ACK to this request, it then sends an accounting start record to RADIUS. It never sends a new authentication request.

If the client releases its lease, then the Mikrotik sends a RADIUS accounting stop record.

So in my observations today, I find that only upon receiving a DHCP discover message from a host not currently in the leases DB does the router bother to send a RADIUS access-request. During testing, I disabled the account of my test client, but was able to renew the lease successfully as much as I liked. Only releasing the IP led to the situation where the Mikrotik would realize that the device was no longer authorized.

In short - the trigger for requesting RADIUS authentication appears to be hit prior to creating new dynamic entries in the leases DB. I must assume that if I were to make some change in the user's RADIUS profile, such as a change to the assigned IP address, queue rates, etc that none of this would make it to the Mikrotik until the existing cached lease is either released or actually expires completely. That's quite problematic from a centralized user-management perspective. Perhaps this is a resurgence of the bug from pre-6.39 versions. I'm about to leave my office for Christmas travel plans, so I don't have time to download, install, and configure the test in v6.39 but I would hope that this behavior I'm seeing is not considered to be "correct" by Mikrotik.

I also plan to test the behavior of RADIUS packet-of-disconnect on radius-backed DHCP leases... Anyway, in case I don't check back in on this thread during the holidays, Merry Christmas to all!

This isn't working yet in RouterOS v6.45beta54.

I want to lock/unlock users using address-list or a blocked-pool/normal-pool, but something must work, like renew to another IP (pool), COA to change Address-list or DM (Disconnect Message) to renew all info.

I have made a lot of tests like
or
All have the same reply
It's seens like the user cannot be found or something like that.
The account is NOT working to, even with a lease of 1 minute, 5m, 10, wharever.

There is a correct way to send radius disconnect request?

I'm not seeing any RADIUS auth requests/responses for renewals of existing leases at the Mikrotik.

Your RADIUS server will have send a Session-Timeout value in the initial Access-Accept. If the renewal time for a new lease exceeds the remaining session time in the original Session-Timeout RADIUS attribute that was originally sent, it will trigger a full re-authentication for the user. If Session-Timeout is not set, it will renew over and over again without checking the RADIUS server again.

I already tried with a lot of combinations, none of then worked.

Someone figure out how to change DHCP Address list or Mikrotik-Rate-Limit using COA?

+, in time. If they read this ,
put in /ip/dhcp-server/lease/print the radius session-id, since I imagine this info is there, this can help when comparing info, logging, etc.

Someone figure out how to change DHCP Address list or Mikrotik-Rate-Limit using COA?

MikroTik does not support CoA with DHCP RADIUS so this is impossible.

As I said, your RADIUS server will have send a Session-Timeout value in the initial Access-Accept. If the renewal time for a new lease exceeds the remaining session time in the original Session-Timeout RADIUS attribute that was originally sent, it will trigger a full re-authentication for the user. If Session-Timeout is not set, it will renew over and over again without checking the RADIUS server again.

That method is officially supported and should work.

IMO, they would never add CoA support for DHCP RADIUS because there is no way of telling a DHCP client that its lease has expired early.

Hi, there

CoA was not to do renew or something like that.

Suppose I have a DHCP client, IP 192.168.1.2 Address-List: has-internet

Then I want to change the user to Address-List: no-internet and apply some firewall rules (block internet).
But the client need to be able to access 'Intranet', like the portal to be billed, etc.
Or I just want to change to Rate-Limit, from 1Mbps to 2Mbps, then go back to 1Mbps or to 512Kbps. etc.
All of this can be done without need to renew the DHCP session.
Just changing address-list or rate-limit.

Plus, I was able to do Access-Request and periodic Account-Request in Mikrotik at the same time.
Just set Interval when reply to Access-Accept then the account works.
Without that, Account just work 1 time in the Start, and on the renew (receive 1 Stop and 1 Start with a new session ID)

Hello softov,

Can you please tell us how you solved the accounting interim updates ?
Can anybody help in this matter:
1. How i can fix the interim updates each minute.
2. Disconnect a user to change his service/pool.

Thanks,
Darkng