• Home
• News
• About FireBrick
• Products

• FireBrick 105
• FireBrick FB6000

• Legacy Products

• Buy Firebrick
• Contact Us
• Support

• Reseller Area

• Press Information

FireBrick FB6000

RADIUS Interface specification

RADIUS is used for authentication and accounting of L2TP connections. If no authentication servers are configured then authentication is not performed. If no accounting servers are configured then no accounting is generated. Multiple servers can be configured and they are processed in order. Each can have multiple IP addresses. The IP addresses are tried at random for each server that has multiple addresses allowing load sharing. If a server does not respond a number of times as configured then it is blacklisted for a configurable period. After the specified number of tries the next server is tried. Eventually the RADIUS will fail if no servers respond or all are blacklisted.

Default operation when no authentication servers respond is TBA. We plan to allow configurable operation for accept, drop, or reject. Default operation when no accounting servers respond is to discard the accounting data.

Authentication

Note that the NAS-IP-Address is normally the local end of the L2TP connection for the incoming connection. However, there is a configuration option to pass the remote end of the L2TP as the NAS-IP-Address as this is often more useful. If the remote Ip is used the NAS-Port is set to the far end L2TP session ID rather than the local end session ID. The NAS-Identified remains the name of the FB6000. This option is separately available for accounting messages.

Note that the Calling-Station-Id is included even if not present in L2TP connection if a cache platform RADIUS request matched the L2TP connection and had a Calling-Station-Id.

Authentication response

For Reject, only Reply-Message is processed. Accept may simply include tunnel relay data. If Tunnel-Server-Endpoint is present then it is assumed that the connection is to be relayed to that endpoint even if no other Tunnel settings exist.

Note that an authentication reject will normally cause the reply message to be sent as an authentication reject message. The reply "Try another" causes the L2TP session to be closed with result/error 2/7 (Try another) without sending an authentication reply on PPP.

Accounting Start

Note that most parameters are not included in interim and stop accounting records. The acct-session-id should be used by accounting servers to correlate interim and stop records with the start record. The graph name could be used, but is only available where there is a graph. If too many different graphs then that is not present. Some exceptions apply as they can be changed by a change of authorisation RADIUS request, such as Connect-Info.

Accounting Interim

Accounting Stop

As accounting interim update plus

Cause codes of note are 2(Lost-Carrier) which is sent if LCP echos do not reply for several seconds, and 14(Port-Suspended) which is sent if the dos-limit is exceeded on a session. For DOS handling is is recommended that subsequent authentication requests are rejected for several minutes or a fake accept is and session-timeout is used as DOS attacks usually continue until the customer is off-line.

Disconnect

A disconnect message is accepted as per RFC5176, if the session can be disconnected, and ACK is sent, else a NAK

The session is identified by Acct-Session-Id if present, else by Chargeable-User-Identity. No other identification parameters are supported. If sent then they are ignored.

Change of Authorisation

A change of authorisation message is accepted as per RFC5176

The session is identified by Acct-Session-Id if present, else by Chargeable-User-Identity. No other identification parameters are supported. If sent then they are ignored.

Parameters are left unchanged if not specified.

No other parameters are supported, and if sent then they are ignored

Filter ID

The Filter-ID can be set in authentication response and change of authorisation. There can be many records. Each can have many filters. Each filter is of the form of a letter possibly followed by number digits. The accounting start lists relevant filters that have been set, each in a separate filter-id AVP. Unknown filters are ignored.

For change of authorisation the absence of a filter has no effect. To set normal routing table 0 zero, send T0. To set not a member of a CUG send A0.

L2TP relay

L2TP relay means that an incoming call (ICRQ) is relayed to another L2TP endpoint. The decision of which calls to relay to what endpoint can be made in one of two ways:-

• Configured pattern match based on calling number, called number, or login
• RADIUS response to initial authentication request advising new endpoint for connection

A test is made against the config on the initial connection based on known data. This is calling number (if present), called number (if present) and login (proxy_auth_name if present). If a match is found the call is relayed with no additional PPP packets exchanged.

If there is no proxy LCP provided, or the provided negotiation conflicts with the configuration, then LCP negotiation is completed.

If there is no proxy authentication, PPP authentication is start until a response/login is received from the peer (assuming authentication is required in the config)

At this point a further check is made for a configured relay which can now be based on a login if one was not present before.

RADIUS authentication is completed, and if the response indicates a relay then the call is relayed

The relayed call includes the incoming call parameters, and any LCP and authentication parameters that may have been negotiated at that point.

LCP echo and CQM graphs

Depending on configuration, LCP echos are faked both ways from the FireBrick, and LCP echos are generated by the FireBrick and responses checked. This allows the CQM graphs to be created. The graph is only created for the outgoing part of the connection. If not configured to fake LCP echos, then these are passed through as normal and no graph is created.

Each session gets a CQM graph which uses one second LCP requests and produces detailed loss/latency graphs for the session. The graph name is picked based on the first available of :-

• Chargeable-User-Identity sent in the RADIUS authentication response
• Calling-Station-Id from L2TP
• User-name in RADIUS athentication response
• Proxy-Auth-Name from L2TP
• Negotiated user name from PAP/CHAP

If a second session starts with the same graph name as an existing session then the existing session is cleared with cause 13(Preempted). It is recommended that a unique circuit ID is passed as the Chargeable-User-Identity in the authentication response to allow simple location of graphs.

Closed User Group

Each session can have a CUG defined (1-32768) which may be allow or restrict. Interfaces (port/VLAN) may also be defined in the same way. A packet from an interface/session with a CUG is tagged with that packet. If the source is restricted that packet can only leave via an interface/session with the same CUG. Similarly if the target interface/session is restricted than only a packet tagged with the same CUG can be sent to it.

Routing table

The FireBrick operates independant routing cores allowing a totally independant routing table to be used for L2TP wrapper traffic and payload traffic. It is also possible to set the payload table in use on a per session basis from RADIUS thus allowing a walled garden to be set up, or a private network, or simple an unusable session.