Authentication of PPPOE sessions when Radius or SQL is down

Network availability is very important to any business. For an ISP it is paramont! We have achieved outstanding results with a network that is 100% Mikrotik. One hole in our deal that I need to resolve is how to authenticate PPPoE clients if radius or the customer database is down. We’re proud to say we no longer run Cisco equipment but with Cisco IOS the command to echieve this was:

aaa authentication ppp default local radius none

This allowed for local authentication then Radius, and if all else failed NO AUTHENTICATION. A negative response from radius kept suspended customers from getting online.

The need to be able to get PPPoE users online in the event of Radius or database issues is urgent. This seems like a feature that would be worthy of consideration. This issue has been discussed in other WISP discussion groups and everyone agrees we need an effective solution.

Steve

use two radius

2 Radius Services are already implemented. There are many potential reasons that Radius or database could be down. The best solution is to let users online at the access server without authentication.

Steve

Hi sir

We implemented a workaround to mimic that requirement, on a customer network that used a single instance of a radius service + mongoDB running on a linux based freeradius platform.

The solution is just for few hundred of subscribers (there was the guarantee of a 400 maximum number of subscribers)

To manage the “rare and sporadic case” ( :slight_smile: ) where radius was down for any reason , we used a script monitoring the radius availability (just checking for timeouts) trough /system script on the mikrotik rb1100 routerboard . When script check fail, the radius is declared unreacheable and it changes the ip of radius dynamically just enabling the radius config entry :

/radius add service=ppp address=127.0.0.1 secret=greencomputing

of course :

  • On the Rb1100 usermanager service is running;
  • A synchronization batch script is needed that clone the username/password provisioned on freeradius radius server db .


    Hoping this will help you in addressing an elegant solution to your specific needings.

have a nice day

you must have two servers, each one with one radius service and one database server.
the servers must be located at your two gateway or in two different strategic position.
The radius clients query the two services and if one radius service or one database service hangs, it query the other.
This is very very secure for a network and it is the canonical way.
You must have at least two servers
and each access server must reach the two servers from two different routes (I am shure this is your case because a 100%availability network must have a lot of rings).

@greencomputing
if you have secrets in list you do not need to have user manager for pppoe auth.

we know that the perfect sys admin has 2 web server, 2 freeradius, 2 router 2 switch and that 2 is better than one in a lot of moment of our daily life but this thread is about a way to mimic the cisco equipment behaviour in case of fall back as described initially by SBastardi

+1 for this.

Then add the user accounts to /ppp secrets, find a way to keep the information in sync, and use it. The capability is there, if radius fails, MT by default fails back to the local user database. Good luck in keeping everything in sync though.

Are you running a business, or a play pen? If you’re running a business, it is important to invest in adequate hardware. I am glad I’m not using your services…

Savage’s suggestion is quite plausible.

The mikrotik API comes to the rescue here. Bear in mind that the ppp secrets is simply the failback here - so its quite practical to wipe and re-add if required ie a one-way sync. If you have many thousands of sessions terminating on a single TIK that will become a real ball ache :wink:

Our typical solution is a radius proxy which monitors the upstream RADIUS servers and essentially enables an ‘any auth’ mode with a low session time. So if you have a radius/customer db failure customers will still be able to auth with a relatively short session time. This allows you to gracefully recover your radius/customerdb as needed.