Home :: Products :: FireBrick FB6000 :: Platform RADIUS

FireBrick FB6000

Platform RADIUS and Session Steering

For incoming L2TP connections it is industry standard to have an initial RADIUS authentication request which can accept/reject the connection before it is passed to L2TP.

There are many ways this can be done, but the common arrangement is to also allow the response to include L2TP tunnel endpoint details allowing the L2TP session to be steered to a particular LNS.

One of the main carriers in the UK is BT, and they have some specific requirements for working with session steering on WMBC links (WBC and IPSC) which the FireBrick handles.

The FireBrick includes a RADIUS service setting which can be used to respond to these platform RADIUS requests and steer new connections in various ways.

How BT handle platform RADIUS

Normally a WBMC link has two WES circuits each with a /30 IPv4 address block. Typical installation is to have two FB6202 L2TP servers, one on each, with an interface facing BT on the /30 block and an interface facing the ISPs core network.

The BT side can be done as a separate routing table, but this is not that useful. So typically the FB6202 has BGP to BT and BGP to the ISPs network.

BT allow two (or, theoretically, more) platform RADIUS IPs. The traffic to these is usually set up as a master/slave configuration, i.e. secondary is only used if first does not respond.

By default these come in on either WES link, even if the IPs are announced by BGP only on only one of the WES links!

Also, they typically alternate links and alternate IPs. This means you cannot, for example, sensibly use the /30 address as a platform RADIUS as you could find consistent wrong IP on wrong link which in the event of a link failure can mean 100% platform RADIUS failure.

What BT actually do is have an internal IP block (typically a /30 allowing 4 addresses) and route the RADIUS to two of these. These are then mapped to your chosen IPs.

Routing to right RADIUS server

The way to direct the platform RADIUS is to announce BTs own RADIUS mapping IPs to BT. The recommendation is to pick two separate IPs for platform RADIUS, typically from your LAN side. One of the FB6202s considered as master and announces the primary BT IP /32 from that to BT. The other announces the secondary BT IP /32 to BT. Both FB6202s have both platform RADIUS IPs as loopback addresses. They answer platform RADIUS with own IP to steer the L2TP to them.

This means you can change which is master and which is secondary by changing which announces which /32 BT IP. This works on-the-fly and is very useful if you want to change which is master, and then systematically ppp kill all lines to flip them to the new master LNS, perhaps over night.

You may want to announce the /30 covering all BT IPs from both. If one LNS fails then both platform RADIUS then go to the other as a result rather than alternating.

Note that you will also need to define IPs for the L2TP endpoints, probably from your LAN, and announce these as /32 from the corresponding FB6202 to BT as well. This ensures the L2TP traffic goes direct to the right LNS FB6202 via its link to BT. You cannot use the /30 endpoint for L2TP for some reason (BT!)

Non session steering BT links

It is possible to have traffic from BT with RADIUS but without session steering. This was the case for 20CN for some time. However BT now allow session steering on 21CN (WBC) and 20CN (IPSC) and this is what we recommend.

If you do not have session steering, it is possible to set each LNS platform RADIUS to give its L2TP IP, and use the master/slave RADIUS to handle fallback. A special require-platform setting on the incoming L2TP will reject any sessions which arrive on the wrong LNS (i.e. the one that did not get the platform RADIUS) which provides a means to steer sessions without using session steering in the platform RADIUS. This is deprecated as BT now handle session steering on all lines.

Authentication

In general you would accept all connections on platform RADIUS, and only when the come in via L2TP do you consider if they are valid (in your own RADIUS server). We recommend that invalid sessions are parked (with a session timeout) on another routing table rather than rejected as otherwise the will retry every few seconds indefinitely. So at the platform RADIUS level you accept all connections.

Session steering

The RADIUS service configuration allows you to define the response to be sent, including the tunnel endpoint details (IP address, hostname, secret). One way to operate is that each LNS is also a platform RADIUS and gives its own IP address as the L2TP endpoint. This is the default response for platform RADIUS.

A better way is to provide multiple endpoints in the response, with priorities set. This allows the connection to come in to the main LNS but have a backup. You can list more than one IP address with one hostname and secret defined.

The FireBrick has a number of options for controlling what LNS endpoint is returned. These can be set for all connections, or based on calling number (circuit ID) or login including pattern matches.

The tagged option controls whether a tagged response is sent with multiple LNS endpoints specified. These then have a preference defined which controls the order in which they are considered based on the order setting. If tagged is not set then only the first entry that would be sent on a tagged list is sent, and it does not have tags or a preference. The order allows you to decide which will be the first in the list.

There are up to two lists of IP addresses, the target-ip and the backup-ip. If the target-ip is missing it is treated as if you had specified the IP being used for the platform RADIUS as the only entry (i.e. "us" as an LNS), and in this case there are defaults for target hostname and secret to match the incoming L2TP configurations.

Strict order

Each of the endpoints in the target-ip list, in order, with increasing preference starting from 1
Each of the endpoints in the backup-ip list, in order, with increasing preference continuing from above

Equal order

One of the endpoints in target-ip picked at random with preference 1
The remaining endpoints in target-ip in order with preference 1
One of the endpoints in backup-ip picked at random with preference 2
The remaining endpoints in backup-ip in order with preference 2

Random or hashed order

One of the endpoints in target-ip picked based on your chosen order logic with preference 1
One of the endpoints in backup-ip picked based on your chosen order logic with preference 2
The remaining endpoints in target-ip in order with preference 3
The remaining endpoints in backup-ip in order with preference 4

The logic to pick one of the endpoints from a list it to make a large (32 bit) number, and modulo it by the number of endpoints in the list, using the result to pick on. The number used is random if you have order="random", otherwise it is taken from the first 4 bytes (high byte first) of an SHA-1 of a string based on the following.

calling	Hashed on calling station id (login if not present)
called	Hashed on called station id (login if not present)
username	Hashed on full login username sent
user	Hashed on username before @
realm	Hashed on username after @
prefix	Hashed on username initial letters and numbers only

This hash is much like a random order except that it is consistent for the same input. This is used because bonding multiple lines needs to have all lines on the same LNS - use of a hash and careful picking of login details can ensure this.

Examples of hashed live and backup LNS

You could have a pool of live LNSs, included in target-ip and one backup LNS in backup-ip. Normally, based on username, sessions would consistently go to the same LNS from the live pool, but all sessions would as a whole be spread out. If one of the live LNSs fails, all of the sessions that would normally go to that LNS will go to the backup LNS.

You could have one live LNS, and a pool of backup LNSs (e.g. live may be FB6202 and backup may be 2700's). Normally all traffic goes to the live LNS, but if that fails then the load is spread over the backup LNSs.

SID into RADIUS

One of the attributes which are included in an L2TP connection is the calling station ID. This was originally the calling phone number, but is commonly a circuit ID. The FireBrick passes this on to your RADIUS server, and it is often useful to verify the exact calling circuit.

Unfortunately, in some cases, the carrier will not send this attribute even though they have the data, instead they include it in the platform RADIUS. This is the case for BT 20CN lines.

When the FireBrick handles a platform RADIUS it caches the calling station ID. If it then receives a matching L2TP connection which has no calling station ID it automatically uses the calling station ID it cached from the platform RADIUS, and includes this in the information sent to your RADIUS server.

This only works where the same FireBrick receives platform RADIUS and L2TP for the connection - which is the default case where using one LNS as master and one as backup. If you use multiple LNSs then the correlation of platform RADIUS and L2TP is not possible. However the FireBrick can be configured to forward a copy of platform RADIUS to your RADIUS server (no reply required) allowing your own RADIUS server to match up the platform RADIUS and L2TP connection RADIUS. Note that matching is best done using CHAP challenge and username.

FireBrick - Firewalls, Bonding ADSL, Routers, Traffic Shaping...