I have implemented a Mikrotik hotspot with mac login and RADIUS authentication.

My captive portal application is hosted externally, and I have customized login.html on the mikrotik to send the mac address and other details to the captive portal application.

After the user performs an appropriate action on the external captive portal (pays for service, etc), the captive portal authorizes the user's mac in RADIUS.

All this works well EXCEPT for this:

• When the user first connects, a RADIUS Auth-Request is sent, and the Mikrotik NAS receives back an Auth-Reject because the user hasn't paid yet
• The user is then of course listed in "/ip hotspot hosts" but not "/ip hotspot active"
• When the user pays and is authorized into RADIUS, as long as they are still in "/ip hotspot hosts" the Mikrotik NAS doesn't send additional Auth-Requests to RADIUS when the user makes attempts to browse the Internet...so even though RADIUS knows the user is authorized, the Mikrotik doesn't re-ask RADIUS and keeps them unauthorized.
• I currently have to manually remove the user from the "/ip hotspot hosts" list after they have been authorized into RADIUS to force the Mikrotik NAS to send a second Auth-Request for them, after which everything works as expected.

I am trying to figure out the right approach to make this process smooth. I have considered

• Send a RADIUS CoA to the Mikrotik NAS after the user pays - I have tested and it seems that I can only CoA a user that has already been Auth-Accepted by RADIUS and appears in both "/ip hotspot hosts" and "/ip hotspot active". I can't CoA a user who was Auth-Rejected and is only in "/ip hotspot hosts" because the Mikrotik doesn't consider them active. The Mikrotik NAS seems to refuse the CoA.
• Enable "http PAP" in addition to "Mac" login in the hotspot profile. Have the external portal redirect the user back to /login.html?username=MAC&password=XXX on the Mikrotik after they have paid. This works, but seems sloppy. I think there is also a hole here where a person could use another user's already authorized MAC as a user/pass to login.
• Instead of Auth-Rejecting unauthorized users, Auth-Accept them with attributes that cause them still to be stuck in the captive portal. Use a CoA once they've paid to change them from limited to full access. This seems like a lot of work, and I'd need to figure out the right attributes for a "limited" Auth-Accept.
• Set "/ip hotspot login-timeout" to something very short, like 3 seconds. This removes any non-logged in users from the "/ip hotspot hosts" list every 3 seconds, and in practice means that almost every web request an unauthorized user makes generates a RADIUS auth request. This seems like what I want, I'm just not sure of the load on RADIUS and the Mikrotik that is created by this.

Questions:

• Is my login-timeout approach the right one?
• Is there a way in a mac-login only scenario, without enabling "http PAP" for my external captive portal to trigger a new Auth-Request from the Mikrotik NAS / hotspot servelet for a previously Auth-Rejected user? I tried just hitting /login with no arguments, but this didn't work.

Thanks in advance!

The login timeout is the best solution for it; however, 3 seconds is too short. Try setting it into 5 minutes.

Thanks for the response!

I agree that setting a 3-5 second login-timeout isn't ideal because of the high volume of RADIUS traffic generated. 5 minutes will be a bit annoying for someone who has paid for a data plan on the external captive portal and then has to wait as long as 5 minutes before it becomes active.

If I could Auth-Accept users but keep them in the walled garden initially - and then use a CoA to allow them full internet access only after they've purchased a data plan that would be ideal.

I wonder if there is an easy way to Auth-Accept someone into a walled garden/limited state? Perhaps through the use of the Mikrotik-Address-List RADIUS attribute or similar? I will experiment with this, but happy to hear input if anyone has made this work!

Maybe you can use framed-pool to attribute. Suspended subscriber will still be authenticated, but will be using a different subnet. Create some firewall rules to redirect them to a specific page where they have the option to reactivate their device after paying their bills. This can be done by using CoA.

The client should simply be able to browse to web page again to be authenticated. Or you could redirect to a non-walled-garden page as the last step in your payment process.

All login processes require a http request. The Hotspot will only resend authorization request if it has not received a response and Auth-Reject is a valid response.

@rdelacruz - that's along the lines of what I'm thinking. Thank you!

@2frogs - the problem I have here is as follows:

--on initially accessing the hotspot in an unauthenticated state, the user connects and tries to browse the internet.
--the mikrotik makes a RADIUS Access-Request request and receives an Access-Reject
--the user is correctly redirected to the external captive portal
--the user correctly makes payment on the external captive portal
--the external captive portal authorizes the user in RADIUS, such that future Access-Requests would receive an Access-Accept
--HOWEVER, subsequent HTTP requests by the client for Internet websites do not trigger Access-Requests. As long as the user remains in the /ip hotspot hosts table and not the /ip hotspot active list - the mikrotik continues to treat them as Access-Rejected, and does not make additional Access-Requests for each HTTP request
--If i remove the user from the /ip hotspot hosts table, another Access-Request is made and all proceeds normally.

Yeah, OK. I do recall this behavior and it is easy to reproduce. Create a disable user with MAC of device. Open browser to be caught by portal, then enable user. Now try browsing again and still get caught by portal. Kick host and will login on next attempt.

You can login using the MAC as user. Redirect the user to maclogin.html. You will need something like the following code; Where they only have to click to continue.

Thanks @2frogs. This is the approach i was describing in my original post as:

Enable "http PAP" in addition to "Mac" login in the hotspot profile. Have the external portal redirect the user back to /login.html?username=MAC&password=XXX on the Mikrotik after they have paid. This works, but seems sloppy. I think there is also a hole here where a person could use another user's already authorized MAC as a user/pass to login.

I did mock this up and make it work, though your approach of using the $(mac) token is better than what I tried - but isn't there a security hole because any user who knew an authorized user's mac could POST a request to this page using the authorized user's mac as username and "steal" the authorized user's access? Or am I missing something?

I wish there was a way to accomplish a seamless login using mac auth only (without enabling PAP auth also)

Not sure it would be any more of a hole than them simply changing their MAC to the same as another user.... shared-user=1 will help prevent this.

Another solution is a script to kick any host that is not authorized that runs every 10-30 seconds. Maybe combine this with a delayed redirect of equal time.

Another solution is a script to kick any host that is not authorized that runs every 10-30 seconds. Maybe combine this with a delayed redirect of equal time.

This can be done with login time-out. However, 10-30 seconds would cause "Already Authorizing, retry later error" if the RADIUS is not done the first authentication request or if the authentication process is still in progress.

This can be done with login time-out. However, 10-30 seconds would cause "Already Authorizing, retry later error" if the RADIUS is not done the first authentication request or if the authentication process is still in progress.

Actually this has no effect on the OP’s issue, it does take the removal of the host before the next capture will login using MAC.

Thanks both for your thoughtful responses. It seems like my best options are:

option 1 - easier, but less elegant
--enable pap in addition to mac login and use an approach like 2frogs example snippet maclogin.html above in which external captive portal redirects user to a page on the Mikrotik hotspot servlet that triggers a new auth request
--set login-timeout to something relatively low like 1m to catch cases in which the redirect to servlet didn't complete for any reason.

option 2 - probably better in the long run, but more work in terms of custom hotspot firewall rules
--Access-Accept everyone, including unauthorized users on the RADIUS end
--use radius attributes + CoA to customize each user's access according to what they do/pay for on the captive portal application.

I wonder how other vendor solutions enabling external captive portals handle this issue. Unifi - for example - handles this scenario well without any particular customization on the network device end. They're not using RADIUS and implement a form of their own "CoA" between controller and AP, so I suppose that's the answer to that question.

Because openwrt is open source, coova-chilli can be used as Captive Portal. Like on more expensive comercial hotspot systems.
coova-chilli can be configured, first to try MAC-auth, when users device associates. In case of success, user can immediately reach the web.
In case of failure, coova-chilli redirects to standard login-page, where user can pay for service, if required, too.
openwrt+coova-chilli use radius for this functionality.

This is another example, that openwrt is better suited for hotspots with "above-basic" features.