Radius alternative for small networks

It is known that the authorization of subscribers via the RADIUS protocol in the operator’s network gives a lot of opportunities - these are tariffs with regard to traffic, the possibility of organizing authorization when accessing the network, Hotspot in Wi-Fi networks and many other things that are difficult to implement without RADIUS.



Often, operators use RADIUS only because they are simply unaware of other authorization methods or do not risk using anything other than the common protocol. In such cases, all the advantages of RADIUS come to naught due to complex server backup methods or their absence. An unexpected disconnection of the billing leads to the disconnection of the Internet for subscribers when the network equipment is operating properly.



Therefore, I would like to talk about how a telecom operator can avoid authorization using the RADIUS protocol on routers with the operating system RouterOS (MikroTik). As a billing, we take LanBilling 2.0, where support is provided for enable, disable, edit, create and delete subscribers. Any system with a similar event mechanism will be suitable for this role with modifications.



Interaction with RouterOS occurs through the API. The first thing to do on the router is to create a dedicated user who will perform remote control.



Access details will be as follows:

Login: api

Password: api

Access only from the billing server: 192.0.2.2





The next step is setting up a firewall that will perform a significant part of the work of blocking subscribers and redirection. For this, it is necessary to allow all subscribers to use selected resources (external DNS server, company website).



# Full access to favorite resources

/ ip firewall filter add chain = forward \

dst-address-list = permited-destinations \

out-interface = ether-wan

Further we use address-list permited-destinations. If necessary, addresses will be added to it, and the firewall rules will remain the same.

Next you need to allow subscribers to visit resources to pay for services. The mechanism described below will provide subscribers with access to all necessary resources for payment.

# Block popular resources that are not needed for payment

/ ip firewall layer7-protocol add name = social-networks \

regexp = vk.com | mail.ru | ok.ru

# We skip subscribers in the process of payment for https-resources

/ ip firewall filter add chain = forward \

dst-port = 443 \

layer7-protocol =! social-networks \

out-interface = ether-wan \

protocol = tcp \

src-address-list = payers-list

Next, we block access to the Internet has not paid for the service. At the time of blocking, billing adds the subscriber IP to the address-list blocked.

# Blocking defaulters

/ ip firewall filter add action = reject chain = forward \

out-interface = ether-wan \

reject-with = icmp-admin-prohibited \

src-address-list = blocked



Next, configure NAT. This is necessary to redirect subscribers to a page with a blocking notification and broadcast addresses of subscribers to access the Internet.



# We are broadcasting all gray addresses

/ ip firewall nat add action = same chain = srcnat \

out-interface = ether-wan same-not-by-dst = yes \

src-address-list = nat-all-abonents \

to-addresses = 203.0.113.0 / 26

# Do not redirect to beggar those who are in the process of payment

/ ip firewall nat add action = accept chain = dstnat \

src-address-list = payers-list

# Redirect to a beggar (192.0.2.3) all others

# defaulters, not forgetting about selected resources

/ ip firewall nat add action = dst-nat chain = dstnat \

dst-address-list =! permited-destinations \

protocol = tcp src-address-list = blocked \

to-addresses = 192.0.2.3 to-ports = 80



The above rules in the forward chain are sufficient to provide access to the Internet. To limit access to the router and provide additional security, you can add several rules to the input chain



After these manipulations, the router can perform the basic functions of accessing subscribers to the network without the aid of RADIUS. The speed of the tariff is limited to / queue simple billing deals with this. Defaulters are automatically blocked, and their requests are redirected to the reminder site. At the same time, debtors still have access to external selected resources (payment services).

Preparing billing

Billing preparation involves writing scripts to handle the activation, deactivation, creation, deletion and editing of the subscriber’s account. We will use Lanbilling as an example.







Additionally, you need to make sure that the LBarcd agent is responsible for the user accounts.







First of all, we show the billing software which scripts and for which events we will use. This is done by changing the parameters in the /etc/billing.conf.LBarcd file.



Each script is called with a specific set of parameters, for each script the set is the same:



login (username in account)

password (user password in the account)

segment (account IP address)

netmask (Mask for IP address in dot-decimal notation. For example, 255.255.255.255)

rate limit (Rate rate for this account in Kilobits. For example, 10240)



The agent event configuration file can be downloaded from the repository on github.

Each event processing script includes a library of functions, which in turn uses a PHP class to work with RouterOS through an API. The source code for each script, function library, and class for working with the API are available in the github repository.

After making changes to the "config" of systems is ready to work. Subscribers who have a positive balance on the account, quietly use the service, and non-payers can only use the local network and allowed sites.

It often happens that the operator has a need to be able to provide the subscriber with an automated temporary inclusion of access, or filling the list of allowed resources with “IPs” of all known payment systems.



For this, a small edit is made in the source code in the subscriber’s personal account. The remaining functions are already configured - the address-list payers-list on MikroTik and the additional function allow_payment in the functions.php library.



In our case, payments are accepted using Yandex.Money, which means we will edit the file

/usr/local/billing/phpclient/client2/client/components/payment/yandex/Payment_Yandex_Pay.php into the processing method of pressing the "Pay" button in the user's personal account.







You must insert a string



file_get_contents (" billing.example.com/tmp_access.php?ip= ". $ _SERVER ["REMOTE_ADDR"]);

before the line

$ this-> post ($ params, $ this-> conf ("operatorURL"));

where billing.example.com is the address of the Lanbilling administrative web interface.



Thus, we send a GET request to our billing script, and as a parameter, we transfer the client's IP address, which is in the personal account and presses the “Pay” button. The contents of the tmp_access.php script can be viewed and downloaded on github. The deleted script adds the subscriber’s IP address to the payers-list with time-out for 20 minutes, after which the subscriber can easily switch to any page for payment.



If the subscriber enters via the mobile Internet, then the list will contain the “left” address of the mobile network, which will be deleted automatically after 20 minutes. If the subscriber comes from the address of the local network of the operator, the system will work in as prescribed. Actually, the same script can be inserted on the page with a warning about payment, where the field for entering the contract number, the amount of payment and the button "Pay" are located.



It is possible to argue with the above, but it is worth taking into account the fact that this solution is not for large networks. Actually, like MikroTik with RouterOS. If there are no more than 3 thousand subscribers in your network, then this method will become the most suitable.



Prepared by Artem Deulin