RADIUS Proxy Service : ROAMING
New version of RADIUS supports proxy service.
Proxy service enables a RADIUS server--the proxy server--to forward
an authentication request from a network access server (NAS) to a remote
RADIUS server and return the remote server's reply to the NAS. A common
use for proxy service is roaming . Roaming permits two or more Internet
service providers (ISPs) to allow each other's users to dial in to either
ISP's network for service. Users traveling outside the area of one ISP's
coverage can access their services through another ISP.
Proxy service also enables an ISP to share its modem pool with that
of neighboring ISPs. Suppose that during peak usage hours the modems of
an ISP are so busy that some users cannot get through. It can establish
a business arrangement with a neighboring ISP--if both are using RADIUS
server, or any other proxy-compatible RADIUS server--so that its users
can dial in to the neighbor's modem pool.
For example, suppose you run an ISP that has such a modem sharing
arrangement. When the users of the other ISP dial in to your modems, your
server contacts the ISP's remote server for authentication and authorization
information. The remote server authenticates the user and sends, through
your server, all the information needed to configure the user's session
on your client.
Because you are in a reciprocal arrangement with the other ISP,
your users can dial in to it and be forwarded to your server. You and the
other ISP can accumulate accounting records for each other's users and
determine how the services are billed.
Each ISP with which you have a business relationship can specify
a server to act as a remote server for proxy service. In some geographic
areas, ISPs are establishing consortia to pool modems throughout the region
by using remote servers.
How Proxy Service Works
A numbered realm is a Called-Station-Id. You can establish
a number for users to call if they need proxy service, and forward proxy
requests based on the number called.
Suppose the user of another ISP dials in to your ISP. Your network
access server-sends its RADIUS access request to the forwarding server
RADIUS server, also known as the proxy server. The RADIUS server parses
the remote server's
realm from the user's request. Your RADIUS
server acts as a client to the remote server and shares a secret with it.
RADIUS forwards the request to the
remote server identified
by the realm. The remote server sends a response (either access-accept,
access-reject, or access-challenge) back to the forwarding server, which
sends it back to the NAS. This process is illustrated in Figure1.
Figure 1 How Proxy Service Works
If the access-request is accepted, the NAS and the forwarding and
remote servers process an accounting-request as follows:
1. The NAS sends an accounting-request to the forwarding
2. The forwarding server writes the request to its accounting
3. The forwarding server forwards the request to the remote server.
4. The remote server logs the accounting-request and sends an
accounting-response to the forwarding server.
5. The forwarding server sends the accounting response to the
Both your forwarding server, which receives the access request directly
from the NAS, and the remote accounting server store the accounting information
in the directories /usr/adm/radacct/
The RADIUS daemon on each server creates the name_or_address directory.
The forwarding server substitutes the name of the NAS for name_or_address.
If the IP address of the NAS cannot be resolved to a hostname, then the
IP address of the NAS is used rather than its name. On the remote server,
the name is based on the hostname (or IP address) of the forwarding server
the request was received from.
If the request is forwarded across a chain of forwarding
servers, the accounting records are stored on all servers in the chain.
Realms. The forwarding server sends the request to
the remote server specified by the authentication realm
are two kinds of realms:
A named realm is the part of a user login following the at
sign (@). For example:
If email@example.com is the user
cornwall.net is the realm.
If sequoyah@cheroke e is the user login, cherokee
is the realm.
A domain name is frequently used as the named realm to provide
RADIUS searches for numbered realms first. If you are using
numbered realms and the RADIUS server must respond to points of presence
(POPs) from multiple area codes, you must specify the area code for each
PortMaster in the proxy file on the RADIUS server.
Servers Running Proxy Service
The forwarding and remote servers can run on different operating
systems. A RADIUS server can function both as a forwarding server and remote
server, acting as a forwarding server for some realms and as a remote server
for other realms. A remote server can in turn forward a request to another
One forwarding server can forward to any number of other forwarding
or remote servers, but only one per realm. A remote server can have any
number of servers forwarding to it and can provide authentication for any
number of realms.
Proxy service requires planning and cooperation between different
business entities. The typical implementation involves a confederation
of businesses designating a single proxy forwarding server to serve as
a clearinghouse server. Within each organization's system,
the forwarding server knows only the address of the clearinghouse server.
The clearinghouse server knows the addresses of all remote servers in the
confederation. Figure 2 shows how this typical proxy confederation works.
Figure 2 One Practical Implementation of Proxy Service
Suppose a NAS sends a proxy request to the RADIUS forwarding server.
If the realm is not found in the proxy file, the request is
forwarded to the clearinghouse server. The clearinghouse server performs
the lookup for the request and forwards the request to the desired remote
server. The remote server sends the appropriate information back to the
clearinghouse server, which in turn passes the information to the original
Each RADIUS server also acts as a remote server to the clearinghouse
server. The clearinghouse server functions as both a forwarding server
and a remote server to the servers at the ends of the confederation.
If you are using a clearinghouse remote server, you can define it
as your default by specifying the realm name DEFAULT
letters). Proxy requests are forwarded to the DEFAULT server if the named
realm has no other entry in the proxy file.
You must ensure that the servers in a proxy system do not
forward to each other, which creates a forwarding loop that passes packets
back and forth between them.
For example, this situation occurs if a proxy file has an incorrect
entry that associates the realm of the next server in the proxy chain with
the IP address of the previous server in the chain.
Configuring Proxy Information on the
To use the proxy service, you must configure RADIUS as you would
normally, with the following additions:
Because the proxy file contains the shared
secrets for the proxy servers, verify that only root users have read and
write access to the file.
You must create a proxy file on each forwarding server.
If you are using any named realms, the remote server must also have a proxy
file so that it can authenticate them. If you are using only numbered realms,
the remote server needs no proxy file.
Components of the proxy File
You create a proxy file in the
directory on the forwarding server and, if necessary, on the remote server.
Each entry or line in the proxy file describes one realm.
Here is a sample proxy file:
#hostname or optional ports
#IP address shared secret realm or keywords
#-------------- ----------------- ------- -----------------
radius.afnog.org vdlk4%#p67w3g&g1 afnog.org
s134.cedeao.org ru83vm7xst1shm!p 5551234 1812 1813
cisco.cybercom.tg ch5#5eb716erth cybercom.tg 1645
rad7.softnet.tg lx4zDFapa3ep softnet.tg 1645 1646 old
NAS1.cafe.tg e997asepdflj cafe.tg old secure
An entry contains the following information, all separated by spaces
Hostname or IP address of the remote server for the realm--a server acting
as a remote server to this server, but which might in turn forward the
Secret shared between this same server and the remote server.
Realm handled by the remote server.
You can optionally include the following additional information
in a proxy file entry:
UDP port number for RADIUS authentication
UDP port number for RADIUS accounting
One or more keywords to affect the server behavior
old --This keyword causes the server to strip
the realm from the login name and not attach Proxy-State when forwarding
access-requests. Use this keyword when you are forwarding requests to servers
with RADIUS versions older than 2.1.
Use the secure keyword with only
if you want certain users to be granted administrative privileges.
secure --This keyword enables the remote server
to authorize someone to log in to your NAS with administrative privileges.
If this keyword is not present, an access-accept message from the forwarding
server to the client that grants administrative access (either Service-Type
= Administrative-User or Service-Type = NAS-Prompt-User) is sent to the
client as an access-reject.
The RADIUS server generates a syslog message similar
to the following (shown on three lines for clarity):
Jul 10 21:10:00 ra radius: remote server 192.168.96.6/1645.4
returned insecure service for client 172.16.3.24/1039.17, sending reject
you can include the optional information in any order in the proxy
entry, after the first three mandatory fields. If you specify
only a single UDP port number, the server interprets this as the RADIUS
authentication port number. If you specify two UDP port numbers, the first
number is interpreted as the RADIUS authentication port and the second
number as the RADIUS accounting port. If you do not specify any ports in
the proxy entry, the server uses its own port numbers for communication
with the remote server.
If a remote server--the final server in the proxy chain--has a proxy
file, the file must have an entry configured for each of the server's own
realms. This entry must include the following information:
Server's own hostname or IP address
Unique shared secret--this secret is not configured on any other device
Realm for which this server is authoritative
Special Realms: DEFAULT and NOREALM
You can include entries in your proxy file for the
special realms DEFAULT and NOREALM. The following example shows sample
DEFAULT and NOREALM entries:
center.com.net e199aespfdx4 DEFAULT
Requests are forwarded to the DEFAULT server if their named realm
has no other entry in the proxy file. You might use the DEFAULT
realm to define the entry for a clearinghouse server.
others.com.net e19aepsfd9x4 NOREALM
When you want users that have no realm to be forwarded to a
specific server, you can create a NOREALM entry for that server. Consider
the situation where for performance reasons you have configured your network
access servers to communicate with many forwarding servers that each have
files but no local users files. You can use the NOREALM entry
in each of these proxy files to forward all the local users--those who
log in without specifying a realm--to your full RADIUS server for authentication.
The last DEFAULT and NOREALM entries in the proxy file are the
ones used. Whenever you update the proxy file, the RADIUS server reads
it into memory in its entirety. The RADIUS server uses the copy in memory
rather than reading the file each time it needs to access a proxy entry.
On the Forwarding Server
The RADIUS clients file must have an entry for the
name or IP address and the shared secret of the NAS. If the forwarding
server is in a chain of multiple servers, the clients file
must contain the name or IP address and the shared secret of any servers
for which it forwards requests.
The proxy file must have an entry for the name
or IP address, shared secret, and realm of all remote RADIUS servers. The
shared secret in the forwarding server's proxy file must match
the shared secret in the remote server's clients file.
Remote in this instance means a server to which the forwarding
server sends a request for authentication. That server might be the ultimate
server in the proxy chain and process the request, or it might in turn
forward the request on, until the request reaches the ultimate server in
the proxy chain and is processed for authentication.
On the Remote Server
The clients file must contain the name or IP address and the
shared secret of all forwarding servers. The shared secret must match the
shared secret in each forwarding server's
If any named realms are used, the proxy file must
contain the name or IP address of the remote server, an unused dummy secret,
and the realm for which this remote server is authoritative. If only numbered
realms are used, then no proxy file needs to be defined on
the remote server.
Figure 3 shows how secrets are shared between devices in a proxy
chain. In this example, shared secrets #2 and #6 can be identical, but
need not be. Shared secrets #3 and #5 can be identical, but need not be.
Figure 3 Shared Secrets
In this example, the server xroad.net acts as a clearinghouse server for
ISPs in Cape Town (radius.co.za) and Lome (radius.tg). The clearinghouse
server proxies requests in both directions.
Figure 4 provides a detailed example of the proxy relationships
To properly configure the components of the proxy service shown
in Figure 4, where each NAS, the administrators must perform the steps
described below. This example considers the case of a user with a home
account in Lome (TOGO) who travels to Cape Town (South Africa).
1. On NAS nas.radius.co.za, enter the following commands
to set the RADIUS authentication and accounting servers:
Figure 4 Proxy Server Relationships
radius-server host 192.168.190.21 1812
radius-server key ujm49fud3$$
2. Determine the IP address or fully qualified domain name of
each NAS and server.
In this example, you have the following from the viewpoint of
someone dialing in to the ISP in Cape Town:
NAS named nas.radius.co.za with IP address 192.168.190.20
Forwarding server named capetown.radius.co.za with an IP
address of 192.168.190.21 in the realm radius.co.za
Clearinghouse server.xroad.net with an IP address of 172.30.140.2
Remote server named lome.radius.tg with an IP address of
172.16.240.111 in the realm radius.tg
NAS named nas.radius.tg with IP address 172.16.240.110
3. On forwarding server capetown.radius.co.za, configure the
Contents of /etc/raddb/clients
¯ Contents of /etc/raddb/proxy
serveur.router.net m72hbtr5$w3xst radius.tg
capetown.radius.co.za secret radius.co.za
DEFAULT can be substituted for the realm radius.tg.
4. On clearinghouse server.xroad.net, configure the following:
Contents of /etc/raddb/clients
Contents of /etc/raddb/proxy
lome.radius.tg qbfja97-8 radius.tg
capetown.radius.co.za thx1984 radius.co.za
5. On remote server lome.radius.tg, configure the following:
Contents of /etc/raddb/clients
Contents of /etc/raddb/proxy
serveur.router.net kntbr352bfd radius.co.za
lome.radius.tg confidential radius.tg
DEFAULT can be substituted for the realm radius.co.za.
6. On NAS NAS.radius.tg, enter the following commands to set
the RADIUS authentication and accounting servers:
radius-server host 172.16.240.111
radius-server key bws5629s$r53
7. Define the user profiles.
You must define a user profile in the users file
of the remote server for each user that is to be authenticated via the
If kodjo a togolese user goes to Cape Town on a business
trip and dials in to the network at radius.co.za, he must enter firstname.lastname@example.org
at the password login prompt.
8. Run the radiusd daemon on servers capetown.radius.co.za,serveur.router.net,
The RADIUS accounting records for proxy users are logged into
the detail file of all the servers.