ClearBox Server™ v1.2 User's Guide

Realms and Packet Forwarding

Very useful reading about proxy chaining, its advantages and implementation is RFC 2607: Proxy Chaining and Policy Implementation in Roaming.


ClearBox Server has built-in support of realms that allow the administrators to define several contexts in which to process authentication and accounting requests. The concept of realm as it is commonly intended in RADIUS environments can be extended by server extension design. It may make it a completely autonomous RADIUS/TACACS+ processing unit within a single server, able to perform authentication and accounting independently from other units (realms) on the same server; this includes the possibility of working with different user databases, accounting databases, etc. If you're an ISP, and you're reselling ports on your access servers to third parties whose users you can recognize by some prefix, suffix, or a particular dialed number, you're probably already using RADIUS realms of some kind.

Realm stripping

ClearBox Server extension can get realm information by different ways. Realm can be stripped from user name or from any other attributes (such as Calling ID or Caller ID).

ClearBox Server allows the server extension to transform user names from the form in which they are received into a form in which they may be properly processed. This may be necessary as the form in which users supply their names to the NAS device (and hence to the RADIUS/TACACS+ server), is not always compatible with the form which ClearBox Server requires to apply its own rules for proxy forwarding, or with the form which the authentication system requires.

Packet Forwarding

ClearBox Server can forward a RADIUS request to another server for processing and relay the other server's result back to its client. We say that ClearBox Server is acting as a "proxy" for the other, "target" server, and that ClearBox Server is "proxy-forwarding", or simply "forwarding" the request to the target server. ClearBox Server fully supports Proxy RADIUS, in that it can act as either proxy or target for either authentication or accounting messages. The proxy functionality can be combined with realms, to provide very flexible roaming services.

The remote server may be chosen based on a part of the username, based on the dialed phone number, or any other piece of information that's available about a request. You can also get the IP addresses and shared secrets for your remote server from any external source you like, so that you can easily maintain these destinations.

TACACS+ Packet Forwarding

TACACS+ protocol design doesn't support proxy-forwarding, and the only way to make TACACS+ packet be sent to another host is to return the host's name in FOLLOW response to the NAS, indicating that the TACACS+ server requests that authentication/authorization/accounting operation should be performed with an alternate server.

Proxy RADIUS Authentication

RADIUS authentication messages are proxy-forwarded as follows:

  1. A RADIUS server receives an authentication message.
  2. The first RADIUS server (the "proxy") forwards the message to the second RADIUS server (the "target").
  3. The target performs the authentication services indicated by the message, and then returns a response message to the proxy.
  4. The proxy relays the response message to its original RADIUS client.

Proxy RADIUS Accounting

RADIUS accounting messages are proxy-forwarded as follows:

  1. A RADIUS server receives an accounting request.
  2. What the RADIUS server does next depends upon how it is designed and configured for proxy accounting. The options are to:
    (a) Forward the accounting message to a target server;
    (b) Record accounting attributes locally on the proxy server; or
    (c) Both (a) and (b).
  3. If the proxy server does not receive an acknowledgement of the forwarded packet, it will re-send periodically according to its retry policy.

During proxy forwarding, ClearBox Server acts as the RADIUS client of another RADIUS server. Since RADIUS clients take responsibility for delivering RADIUS packets, all of them have a "retry policy" that determines how often and for how long they will continue to try to deliver a packet until they receive the response that they expect from the RADIUS server. This includes ClearBox Server when it acts as the RADIUS client of a Proxy RADIUS target server.

ClearBox Server is sending a packet to a target, and if it is not getting a response within the amount of time it expects, it keeps trying periodically to send the packet until it has used up the number of attempts in its retry policy. This policy is determined by a server extension used by server.

Attribute Filtering

ClearBox Server is able to filter specific RADIUS attribute/value pairs into and out of RADIUS packets as they travel to and from a target RADIUS server. This can be useful, for example, if there is data in the packets that is needed for routing, but not for authentication or accounting. Attribute filtering is able to add, remove or change any RADIUS attributes in both request and response packets.

© 2001-2003 XPerience Technologies.

Created by chm2web html help conversion utility.