Eltex-RADIUS allows proxying to a home server. By default, the opportunity is available only for authorization requests proxying to one server. The section describes how to configure both authorization and accounting proxying to one or more servers.
Proxying default configuration is located in /etc/eltex-radius/local.conf file and looks like this:
# Proxying proxy_auth=0 proxy_domain_regex="^(.+\.)?enterprise\.root$" proxy_host="127.0.0.1" proxy_port=18121 proxy_secret="eltex" |
proxy_auth – proxying status, allowed values – 0 and 1, 0 by default, disabledproxy_domain_regex – a regular expression that defines domains in which authorization requests will be proxied to proxy all requests, set this parameter to "^(.+\.)?root$"proxy_host – an address of a home server requests will be proxied toproxy_port – a server's interfaceproxy_secret – a key set on a home server for Eltex-RADIUS serverremember that Eltex-RADIUS will act as NAS within such a configurationIn this configuration eltex-radius will act as NAS. |
More delicate adjustment can be done in /etc/eltex-radius/proxy.conf in the following way:
# -*- text -*-
##
## proxy.conf -- proxy radius and realm configuration directives
##
proxy server {
default_fallback = no
}
home_server auth_proxy {
type = auth
ipaddr = "${proxy_host}"
port = "${proxy_port}"
secret = "${proxy_secret}"
response_window = 20
#
# Start "zombie_period" after this many responses have
# timed out.
#
# response_timeouts = 1
zombie_period = 40
revive_interval = 120
status_check = status-server
check_interval = 30
check_timeout = 4
num_answers_to_alive = 3
max_outstanding = 65536
}
home_server_pool auth_proxy_failover {
type = fail-over
home_server = auth_proxy
}
realm auth_proxy {
auth_pool = auth_proxy_failover
}
realm LOCAL {
# If we do not specify a server pool, the realm is LOCAL, and
# requests are not proxied to it.
}
#realm "~(.*\.)*example\.net$" {
# auth_pool = my_auth_failover
#}
# Proxy SSID (for example to eltex-eap-tls) #139679
home_server auth_ssid {
type = auth
ipaddr = "${proxy_ssid_host}"
port = "${proxy_ssid_port}"
secret = "${proxy_ssid_secret}"
response_window = 20
#response_timeouts = 1
zombie_period = 40
revive_interval = 120
status_check = status-server
check_interval = 30
check_timeout = 4
num_answers_to_alive = 3
max_outstanding = 65536
}
home_server_pool auth_ssid_failover {
type = fail-over
home_server = auth_ssid
}
realm auth_ssid {
auth_pool = auth_ssid_failover
} |
The simplest case is proxying authorization requests to one home RADIUS server.
To do this, modify /etc/eltex-radius/local.conf file in a following way:
# Proxying proxy_auth=1 proxy_domain_regex="^(.+\.)?enterprise\.root$" proxy_host="10.10.10.11" proxy_port=1812 proxy_secret="topsecret" |
According to the configuration, all authorization requests in enterprise.root domain hierarchy will be proxied to 1812 port of a server with 10.10.10.11 address, topsecret will be used as a secret.
| According to the configuration, accounting will still be processed locally, i.e., by Eltex-RADIUS. |
/etc/eltex-radius/proxy.conf file modification is not required.
To proxy accounting requests as well as authorization requests, modify /etc/eltex-radius/proxy.conf file file.
In the section home_server, change a value of type parameter to auth+acct:
home_server auth_proxy {
type = auth+acct
ipaddr = "${proxy_host}"
port = "${proxy_port}"
secret = "${proxy_secret}"
response_window = 20
#
# Start "zombie_period" after this many responses have
# timed out.
#
# response_timeouts = 1
zombie_period = 40
revive_interval = 120
status_check = status-server
check_interval = 30
check_timeout = 4
num_answers_to_alive = 3
max_outstanding = 65536
} |
In the section realm auth proxy, replace the parameter auth_pool to pool, the value should remain the same:
realm auth_proxy {
pool = auth_proxy_failover
} |
In the file /etc/eltex-radius/servers/default, add a line proxy_auth after preprocess in preacct section:
preacct {
preprocess
proxy_auth
acct_counters64
acct_unique
acct_ciscoavpair
# Parse common cisco-avp ('domain' for example)
common_ciscoavpair
rewrite_called_station_id
if (${pcrf_enabled} == 0) {
fill_ap_domain
fill_ssid_security
}
files
} |
This option requires significant modification of configuration files. Proxying to two home servers will be considered below, but the method suggested is also available for further scaling.
Edit /etc/eltex-radius/local.conf by adding host, port and secret individual parameters for each home server:
# Proxying proxy_auth=1 proxy_domain_regex="^(.+\.)?root$" proxy1_host="10.10.10.11" proxy1_port=1812 proxy1_secret="topsecret" proxy2_host="10.10.10.12" proxy2_port=1812 proxy2_secret="topsecret" |
Modify /etc/eltex-radius/local.conf in accordance with the configuration above. home_server section with unique name should be described for each server.
All home_server should be added to home_server_pool that, in turn, should be added to auth_proxy realm. As both accounting and authorization are intended to be proxied, the parameter that points to the pool should be named pool.
home_server auth_proxy1 {
type = auth+acct
ipaddr = "${proxy1_host}"
port = "${proxy1_port}"
secret = "${proxy1_secret}"
response_window = 20
#
# Start "zombie_period" after this many responses have
# timed out.
#
# response_timeouts = 1
zombie_period = 40
revive_interval = 120
status_check = status-server
check_interval = 30
check_timeout = 4
num_answers_to_alive = 3
max_outstanding = 65536
}
home_server auth_proxy2 {
type = auth+acct
ipaddr = "${proxy2_host}"
port = "${proxy2_port}"
secret = "${proxy2_secret}"
response_window = 20
zombie_period = 40
revive_interval = 120
status_check = status-server
check_interval = 30
check_timeout = 4
num_answers_to_alive = 3
max_outstanding = 65536
}
home_server_pool auth_proxy_failover {
type = fail-over
home_server = auth_proxy1
home_server = auth_proxy2
}
realm auth_proxy {
pool = auth_proxy_failover
} |
Add a line proxy_auth after preprocess to preacct section of /etc/eltex-radius/servers/default file, as described above.
| The configuration considered configures failover proxying between home servers and is set via type parameter in home_server_pool section. The load-balancing mode is also available, follow link 2 in the Sources section for detailed information. |
This configuration may be required for partial, step-by-step transfers of clients from one proxy server to another.
In the configuration below, the Central, North-West domains are processed on the old server, while South and Volga are transferred to the new one. After the 'transfer' (e.g. North-West from proxy_domain_regex to proxy_domain_regex_2) the main Eltex-RADIUS must be restarted.
To work with two proxying conditions and two servers, you have to change the configuration as follows:
Add the second domain group in /etc/eltex-radius/local.conf file
# Proxying (configure the first domain group) proxy_auth=1 proxy_domain_regex="^(.+\.)?(Central|North-West)\.root$" proxy_host="1.1.1.1" proxy_port=1812 proxy_secret="password1" # add the second domain group proxy_domain_regex_2="^(.+\.)?(South|Volga)\.root$" proxy_host_2="2.2.2.2" proxy_port_2=1812 proxy_secret_2="password2" |
Add the second server in /etc/eltex-radius/proxy.conf file
home_server auth_proxy_2 {
type = auth
ipaddr = "${proxy_host_2}"
port = "${proxy_port_2}"
secret = "${proxy_secret_2}"
response_window = 20
#
# Start "zombie_period" after this many responses have
# timed out.
#
# response_timeouts = 1
zombie_period = 40
revive_interval = 120
status_check = status-server
check_interval = 30
check_timeout = 4
num_answers_to_alive = 3
max_outstanding = 65536
}
home_server_pool auth_proxy_failover_2 {
type = fail-over
home_server = auth_proxy_2
}
realm auth_proxy_2 {
auth_pool = auth_proxy_failover_2
} |
Add the second proxying condition in /etc/eltex-radius/policy.d/proxy file
# Proxy Domain
proxy_auth {
if ("${proxy_auth}" == 1) {
if (&Eltex-Domain && &Eltex-Domain =~ /${proxy_domain_regex}/) {
update control {
Proxy-To-Realm = "auth_proxy"
}
# If request is going to be proxied, local processing is pointless
handled
}
if (&Eltex-Domain && &Eltex-Domain =~ /${proxy_domain_regex_2}/) {
update control {
Proxy-To-Realm = "auth_proxy_2"
}
# If request is going to be proxied, local processing is pointless
handled
}
}
} |
After that you only need to restart Eltex-RADIUS.
You can check how the proxying works by looking into debugging. In the given example, you can see how authorization to SSID South in the South.root domain is proxied to home server 2.2.2.2.
sudo eraddebug (0) Wed Jun 16 14:35:15 2021: Debug: Starting proxy to home server 2.2.2.2 port 1812 (0) Wed Jun 16 14:35:15 2021: Debug: Sent Access-Request Id 232 from 0.0.0.0:32770 to 2.2.2.2:1812 length 221 (0) Wed Jun 16 14:35:15 2021: Debug: User-Name = "test" (0) Wed Jun 16 14:35:15 2021: Debug: NAS-IP-Address = 10.25.96.115 (0) Wed Jun 16 14:35:15 2021: Debug: NAS-Identifier = "A8-F9-4B-B2-48-EA" (0) Wed Jun 16 14:35:15 2021: Debug: NAS-Port-Id = "10" (0) Wed Jun 16 14:35:15 2021: Debug: NAS-Port = 0 (0) Wed Jun 16 14:35:15 2021: Debug: Called-Station-Id = "A8-F9-4B-B2-48-E0:South" (0) Wed Jun 16 14:35:18 2021: Debug: Eltex-Domain = "South.root" |
When proxying is performed, home server's status checking mechanism is enabled by default. If a home server does not respond for some time, and then becomes available again, then proxying will resume only when that server responds to status-server request.
During operation, a situation may arise where the counter server does not know how to respond to the status-server, or it is not properly configured. In such a case, this check can be disabled on the proxying server.
To do that, the following changes are required:
In /etc/eltex-radiu/proxy.conf file:
in home_server auth_proxy section, set the following:
status_check = none, is set to status-server by default
revive_interval = 60, 120 by default
in home_server_pool auth_proxy_failover section, set the following:
type = fail-over, set to load-balance by default
After that, restart the service with the following command:
service eltex-radius restart |
As a result, if the connection between the servers fails, the service will become available in 60 seconds after re-establishing connection.