Radius Proxy Guide
DataTill allows the proxy of radius requests between multiple DataTill instances.
1. Overview:
DataTill supports radius request proxying between instances—allowing a primary installation to forward requests to a secondary, or even bidirectional forwarding if configured. This is achieved via configured realms, which redirect matching radius authentication and accounting requests to the appropriate instance. Proxied sessions appear as active on the primary DataTill, despite lacking user account details, while full user and product info shows on the secondary instance’s session screen.
2. Defining User Realms:
There are two ways of defining the realm used to trigger a remote proxy authentication on a remote radius server.
2.1. Traditional Realm:
The first scenario is to use a realm, for example: john@myisp.com. In this example myisp.com is the realm that is used to redirect the user to the remote proxy for authentication.
Note that the realm will be stripped from the username when the secondary radius server receives the radius request. If the realm is required by the secondary radius server as part of the username, then the second method (prefix) described below will be required.
2.2. Username Prefix:
In prefix-based scenarios—such as myisp.com/john—the realm remains myisp.com, and the auth request is forwarded to the remote proxy. Prefixes and suffixes can be used together (e.g. myisp/john@myisp.com), where myisp determines the remote realm and john@myisp.com is passed through as the username. If the suffix needs to be retained in the proxy request, a prefix must be used; otherwise, the suffix is stripped. When myisp/john@myisp.com is set on the CPE, the secondary radius server will authenticate john@myisp.com.
3. Configuration:
3.1. Primary Radius Server:
The primary DataTill instance is where the auth request will first be seen. This is the radius server that will redirect the request to the secondary radius server. The username that is being checked for authentication must not exist on this radius server.
3.1.1. Configuration File:
Edit the /etc/free radius/custom_proxy.conf file and scroll to the very bottom of the file.
Paste the following code below all other text and replace all the words market in bold and purple with the appropriate values:
home_server my_realm_name {
type = auth+acct
ipaddr = 1.2.3.4
src_ipaddr = 1.1.1.1
port = 1812
secret = xxxxxxxxxxxxx
require_message_authenticator = yes
}
home_server_pool cloud_auth {
type = fail-over
home_server = my_realm_name
}
realm my_realm_name.co.za {
type = radius
pool = cloud_auth
}
realm – In this code snippet above the realm used is my_realm_name.co.za,
ipaddr – The IP address to forward any radius requests for any user that matches that realm is 1.2.3.4.
src_ipaddr – The src address that will appear on the secondary radius server is 1.1.1.1. There must be a valid NAS configured on the secondary radius for this IP address, else these proxied radius requests will be rejected by the secondary radius server.
secret – this password must match the secret used on the NAS with matching IP address configured on the remote radius server.
Note that the nostrip option can be added to the realm section. This will result in the full username containing the realm be passed on to the proxy server for authentication. Bear in mind that MSChapV2 auth can only be used in the proxied radius server if the nostril option is used.
3.1.2. Ports:
Port 1700 must allow incoming requests from the remote or secondary radius server. This will be used to send disconnect requests from the secondary radius to the primary radius, as the secondary radius does not talk to the originating NAS devices directly, but via the primary radius server.
3.1.3. NAS:
The secondary DataTill server’s IP must be configured as a NAS on the primary DataTill installation. Also ensure that the secret used matches the secret defined in the proxy.conf file.
4. Remote Radius Server:
The remote radius server is the secondary DataTill instance that will process the auth request. It is here where the radius account must exist.
4.1 Configuration File:
No configuration file changes are required. The proxied radius requests will appear as if coming from a normal NAS device. The NAS device IP address will be that of the the primary Data Server.
4.2 NAS:
The primary DataTill server’s IP must be configured as a NAS on the secondary DataTill installation. Also ensure that the secret used matches the secret defined in the proxy.conf file.
4.3 Ports:
Ports 1812 & 1813 must allow incoming radius requests from the primary radius server.
5. UBNT & Mikrotik Devices:
Note that when the primary radius server strips the realm from the username during the proxy request the authentication will fail if MSChapV2 is used. In those scenarios switch your CPE device to using MSChapV1 instead. If the realm is retained during the proxy request, then MSChapV2 authentication can be used.
To switch the CPE devices to use MSChapV1 instead of MSchapV2 authentication use the following instructions:
Ensure that the authentication protocol mschap2 is disabled on your PPP server on the highsite and that mschap2 is disabled on your clients PPP account.
If mscap2 is not disabled, then radius auth requests will not be successfully managed by the secondary radius server.
5.1. Mikrotik NAS.
PPP service on Mikrotik NAS device:
5.2. Client Devices:
PPPoE dialup setup on Mikrotik CPE device:
PPPoE Dialup Setup on UBNT CPE Device:
6. Testing the Proxy Setup:
After editing the proxy.conf file, restart the primary Radius service to apply changes. If there’s a syntax error, the service may fail to restart—so double-check all file edits carefully.
To test the that the proxy setup is working execute the following command on the primary radius server:
usr/local/bin/radtest proxy_test@myisp.com ‘my_password’ 127.0.0.1 10 nas_secret
(Replace username@realm, my_pssword and nas_secret with the settings)
The output should look similar to the following:
Sending Access-Request of id 123 to 127.0.0.1 port 1812
Username = “proxy_test@myisp.com”
User-Password = “1212”
NAS-IP-Address = 196.1.2.3
NAS-Port = 10
Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=123, length=55
Acct-Interim-Interval = 300
Mikrotik-Rate-Limit = “1048576/1048576”
Session-Timeout = 1497420