Splynx Radius server

Splynx ISP framework consists of different sub-systems. One of the main and most important parts of the framework is Splynx Radius server. PPPoE, DHCP, IPoE, Hotspot, Wireless or Static IP/MAC authentication. Splynx solution also provides smart bandwidth management, billing other useful features.

Splynx Radius server is used to perform AAA tasks.
Authentication – Networking equipment perform check over Radius server if login/password of connecting device or user is correct. If it matches with an entry in Radius server, device or user is able to access the equipment or get the service.
Authorization – defines which actions are allowed for user or device and it’s privilege level.
Accounting – statistics of the usage of Internet or information about what was done on equipment.

1. Administrative AAA.
Authentication: With Splynx you can setup that when administrator accesses equipment, his credentials will be checked over Radius server database.
If his username/password is correct, he will be able to login to equipment. If not, he will not get access. This is very convenient approach comparing to local login.
Imagine when you hire a new administrator and you need to update hundreds of routers, APs and switches to create him local login everywhere.
Or you can give him one common login/password, but when a person leaves the company, you should change that credentials everywhere.
Better is to connect all networking devices to Radius server and verify administrator login using Radius protocol.
Authorization: means that different levels of access can be implemented. Some administrators can change the configurations, some can only view and read config.
Accounting: Splynx stores information of when the network unit was accessed by an administrator and what was done there.

Below are tutorials showing how to configure admin login using Radius Splynx server on different platforms :

Mikrotik: Radius admin login to Mikrotik routers

Administrative login to Cisco devices

2. Customer’s AAA.
Splynx Radius server supports different ways of customers’ central authentication in the network of Internet provider. It always depends on the topology of an ISP and technology that he decides to use. Access technologies are widely used and their advantages and disadvantages are described below:

PPPoE – easy to maintain and implement. Customer on CPE device setups username and password and all networking settings CPE receives from PPPoE NAS (Network Access Server). Also provides encryption if needed and accounting for getting statistics of usage. Had issues with MTU in the past, but in last years these issues were fixed by main vendors.

IPoE (or DHCP) – DHCP is based on MAC address of the client. Also can be linked to the port of switch were a customer is connected (DHCP option 82). In several vendors don’t provide accounting capability (Mikrotik routers).

Wireless Authentication – when ISP has a wireless network, he needs to maintain access of CPE devices to his Access Points. For this purpose, several wireless authentication methods are used, such as a password inside TDMA protocols or wireless access-lists.

Hotspot – customer has to enter his username and password on the webpage before using the Internet. Many hotspot networks allow free limited access and then charge customers for additional usage or advanced plans.

Static IP addressing – some ISPs don’t have central management of authentication and setup static IP addresses to CPE devices. With Mikrotik RouterOS platform Splynx can manage even customers who’s got static IPs in Vlan per customer or plain IPv4 connection. Also Splynx can grab statistics from Mikrotik routers for such customers.

Below are manuals for different types of user authentication in Splynx ISP Framework :

Mikrotik: DHCP using Radius

Mikrotik: PPPoE and other PPP tunnels using Radius

Mikrotik: Hotstpot with Radius

Mikrotik: Static IP addressing with API authentication/accounting

Mikrotik: Local DHCP with Mikrotik API

Ubiquiti: Wireless authentication with Radius

Ubiquiti: PPPoE authentication on Edge Routers

Cisco: PPPoE with Radius

Cambium: Wireless Authentication via Radius


Should you have any questions regarding Splynx RADIUS server or further information is needed, please contact us or schedule a call with our engineer.

Splynx Radius configuration and troubleshooting

This is a post showing how to troubleshoot communication between router (Mikrotik example) and Radius.

Video tutorial for Radius configuration can be found here – https://splynx.com/384/ispframework-and-radius-mikrotik-example/. Below are steps for Radius and Splynx configuration:

Step 1. Mikrotik Radius section
To configure Mikrotik router and Radius authentication, we should change the settings in Mikrotik Radius section.
1) Choose services, that have to be authenticated by Radius (ppp, DHCP, login etc.)
2) Enter IP address = Splynx IP address, reachable from Mikrotik
3) Secret = this value is located at Splynx -> Router -> Edit -> Radius secret

mikrotik_router_radius

4) We cannot use more than one Radius server per Service

router_radius

Step 2. MikroTik PPP (in case when PPPoE is used)
1) Enable on Secrets -> PPP Authentication & Accounting features “Use radius (yes), Accounting (yes)”

ppp_authentication

2) Set Profile – default or default-encrypted, set Local address (it’s IP of Mikrotik router for establishing PPP connections)

ppp_local_address

Step 2. MikroTik DHCP
If we use IPoE authentication (DHCP), we should enable Radius communication on DHCP server.

radius_dhcp

Step 2. MikroTik Hotspot
For enabling Radius hotspot authentication, please, change the Hotspot configuration of Mikrotik under IP -> Hotspot as shown below:

radius_hotspot

When we enable services for Radius authentication, we can move forward and configure router in Splynx.

Step 3. Splynx router configuration
Splynx -> Networking -> Routers, here you can edit or change router settings. Important fields to fill are :
1) Radius Secret should be same as in Mikrotik settings
2) IP/Host –  the real IP (or host, or dyndns host) from which Mikrotik sends packets. In case when NAT is between Mikrotik and Splynx Radius, host IP will be public IP of NAT router and real IP will be private IP of Mikrotik router.
3) Authorization/Accounting – please set DHCP/PPP/HotSpot Radius. Even if you choose PPP, DHCP and Hotspot authentication will work as well. The difference is in DHCP Radius, here you can find accounting API. It means that for getting statistics from DHCP server, Splynx should connect to API of Mikrotik. This is caused by unsupported Radius accounting packets on Mikrotik routers.
4) NAS IP – IP address of router (on radius packet – NAS-IP-Address), in case when you use hostname of router you need to set this IP. (you can set this ip on Mikrotik  – Radius – Src. Address)

radius_settings

Step 4. Define IP networks for IP assignments
Splynx -> Networking -> IPv4 networks
1) Add some network for dynamic assignment (pool) or permanent (static) usage

networks

Step 5. Activate customer and set the Internet service
When we have added router and networks to Splynx, it’s the right time to add a customer and activate him

active

Then, we need to create an Internet service for the customer with PPP details (or MAC in case of DHCP authentication), IP address and other details.

service

If all these steps were made and still Mikrotik router shows Radius timeout in log, then, we need to make a quick troubleshooting.

Troubleshooting
First of all, check the file in Splynx logs called radius/short. It can be found in section Splynx -> Administration -> Logs -> Files. If this file is empty, Radius server should be set to debug mode.

Splynx Radius server consist of 2 daemons – splynx_radd and freeradius. Both of them have different debugging and show different information. Let’s start with splynx_radd debugging :

To enable debug mode of Splynx, connect via SSH to Splynx server and change the configuration file: /var/www/splynx/config/radius.php
[debug] section enable should be changed to – “true

To restart Radius server, enter command in SSH : service splynx_radd restart

Now we can check the debug file, again it’s accessible from CLI of Linux Splynx server:
/var/www/splynx/logs/radius/debug.log
The best way to check the file is command tail -f /var/www/splynx/logs/radius/debug.log

If splynx_radd debug doesn’t show us anything, we can try to run freeradius daemon in debug mode and see if any packets are received by Radius server.

Run CLI commands :
service freeradius stop
freeradius -Xxxx

and check the CLI console output.

If you don’t see any debug messages when customer tries to connect to Mikrotik Router, it means that your router cannot send packets and connect to Radius server at all. It means that you have to verify networking, routing and NAT settings of the network.

On Mikrotik Router there is also availability to run extended debug to see what exactly router is sending to Radius server :

debug_router

Contention in Splynx (aggregation of users)

Splynx provides the feature of contention or aggregation. This feature is used when ISP sells to the end users services with contention rate for example 1:5, 1:10 etc. Contention means that end user will share the bandwidth with other end users in his group.

Splynx operates with two types of contention: Per plan based and per router contention.

1. Plan based contention.
Let’s take a look on example.
We are selling to the end users plan 5 Mbps with contention rate 1:5. It means, that Splynx will setup the parent speed-limit of 5 Mbps and under this parent it will place 5 users with speed-limit of 5 Mbps each. What will happen in this situation: if line is free and one user starts to download/upload, he gets full 5 Mbps throughput. In case, when second user actively starts downloading, they will get 2,5 Mbps each. When all 5 users will simultaneously download with maximum speed, they will share the bandwidth.

It’s described in the image below:

Plan1

 

 

 

 

 

 

 

 

 

 

We can tune a bit sharing of speed with setting up “Limit-at” or guaranteed speed. If we place 1 Mbps to each user, then all users will always get at least 1 Mbps.

In that case all 5 users will simultaneously download with 1 Mbps speed. It’s shown on a second screenshot.

Plan2

 

 

 

 

 

 

 

 

 

 

What will happen in situation, when we will put 7 users on 1:5 contention plan ? Splynx will change the parent speed to 7 Mbps in this particular case, but will leave maximum speed of each user on 5 Mbps.

Plan4

 

 

 

 

 

 

 

 

 

 

 

 

 

If you are planning to deploy Plan-based contentions, use it on central routers to achieve high amounts of users in one tree. Compare two situations – 1:5 contention tree with 5 users and two of them are hard downloaders, it means that 3 other users will never get 5 Mbps speed, because they are all under one common parent of 5 Mbps.

If we place 20 users on this contention 1:5, then parent maximum speed will be set to 20 Mbps and then two or more high downloaders will not use the whole bandwidth.

Plan5

2. Router based contention.

Router based contention is used in this scenario:

Imagine that we have a wireless AP which is connected to backbone network with 30 Mbps speed. But we connected to that AP users with total possible bandwidth of 60 Mbps. What can happen in a peak time is that users will consume more traffic than can be sent through uplink. It means that wireless link can become overutilized and unstable. It’s shown in the picture below.

Topology-Router1

To prevent this situation, router based contention can be used. In Splynx each router has field “Sector/Speed limits”, where can be defined groups and administrator can put users under these groups. As a result we will achieve contention per router :

Router4

 

 

 

 

 

 

 

 

 

 

 

 

 

In a short video tutorial you can find how to configure Splynx and Plan based contention:

Configuration of Router based contention is shown on other video:

 

Blocking of non paying customers in Splynx

 

Splynx blocks non paying customers automatically. Also administrator can block the customer manually. When customer is put to Blocked or Inactive status, Splynx sends to router command to block him. If status is changed to Block – Splynx never cuts the service, but places the IP of end user to Address-list or give hime IP address from IP pool for blocked customers. Then administrator can create a rule on router for redirection of non-payers to a special page.

Splynx has 4 default blocking pages which are located at : http://yoursplynxurl:8101, http://yoursplynxurl:8102, http://yoursplynxurl:8103 and http://yoursplynxurl:8104

It’s a simple HTML file, which you can change via command line inside your splynx installation (SSH) at  /var/www/splynx/web/errors/ and folders 1,2,3,4 correspond to ports 8101, 8102, 8103 and 8104

Example of default blocking page is shown below :

2016-09-02 03.53.25 pm

Example of how the page can be customized :

2016-09-02 03.52.51 pm

There are 4 types of blocking scenarios :

1. Mikrotik API blocking
If you use Mikrotik based authentication – Hotspot, DHCP, Wireless or PPP, then as the first step, you should enable API blocking of users. It’s called “Disabled customers to Address-List” in Router API settings:

disabled

When customer is moved to status “Blocked”, his IP address is put to address list “SpLBL_blocked”. With setting up the rules for redirection, you can achieve that customer will see a special webpage with information why his access to the Internet was blocked.

2. Radius COA blocking
In Radius by default we also work with Addres-lists. Splynx uses names of address lists Reject_1, Reject_2, Reject_3 and Reject_4 for different type of errors. The names of address lists are configured under Config -> Networking -> Radius and also under field COA Block attributes:

2016-09-02 04.18.24 pm

3. Radius Session disconnection
The difference between Radius COA block and session blocking is that with COA session of customer is not disconnected, while in Session blocking his session is cut and user must reconnect his device.

The setting how to block user is defined in Config -> Networking -> Radius “Customer Block” and “FUP Block”:

2016-09-03 02.17.07 pm

4. Radius IP pool blocking
If customer gets IP from dynamic pool, or when NAS router is not a Mikrotik, Splynx gives to the blocked customer IP from Reject IP pools. By default these pools are 10.250.25x.0/24, but it can be changed in Config -> Networking -> Radius as shown on screenshot below:

2016-09-02 04.17.17 pm

If you use Mikrotik routers, there are 2 rules to redirect all TCP traffic to the blocking webpage and to cut all other traffic like Peer to peer connections (redirect them to router itself):

/ip firewall nat add action=dst-nat chain=dstnat protocol=tcp src-address-list=Reject_1 to-addresses=10.0.1.158 to-ports=8101
/ip firewall nat add action=redirect chain=dstnat protocol=!tcp src-address-list=Reject_1

All four methods of Splynx user blocking  you can find on our video tutorials:

Mikrotik API blocking of non payers

Radius COA blocking of non payers

Radius code disconnect (session reset)

Radius reject IP pool assignment


Should you have any questions regarding user blocking in Splynx or you just want to try it in action, feel free to contact us.