(RADIATOR) DSL Auth setup

Martin Wallner Martin.Wallner at etel.at
Tue Aug 14 09:12:14 CDT 2007


Adam, 

we have pretty much the same setup (mixed dialup, dsl, some of these
with special routes and then, as a cherry on the top, nice VRF's). 

Standard for us is to pack it all in an LDAP-Schema (due to inheritation
it's not a 'standard' schema), which includes radius reply and radius
check fields for the dynamic reply/check fields. The 'static'
replyfields are glued in with 'AddToReplyIfNotExist' - and so can be
overwritten if something changes, simply by entering the correct field
to the user/pass pair in the dn ... This takes more preparation, but
should be your final target, just because the LDAP-Authentication is a
lot faster than doing it anyway else (IMHO). 

You can also do it with AuthBySQL, and use the reply and check fields
like it's shown in the examples... that is the 'fastest' way to do this,
if you just stuff all dynamic valuepairs (including the avpairs) in the
Replyfield of the database row, make the same AddToReply... for the
standard things... Done.

We have now about 100000 different entries in the LDAP and around 1500
(for test purposes) on SQL-Authentication. Since there are sufficient
Editors built, maintainance can be hold up until the Applications
Department does it 'comftable' :-)

=mw=



-----Original Message-----
From: owner-radiator at open.com.au [mailto:owner-radiator at open.com.au] On
Behalf Of Adam Armstrong
Sent: Dienstag, 14. August 2007 13:00
To: Hugh Irvine; radiator at open.com.au
Subject: Re: (RADIATOR) DSL Auth setup

Hugh Irvine wrote:
>
> Hello Adam -
>
> Can you give us a bit more detail on your requirements?
>
> You mention a "flat file mess" - do you need to use flat files or 
> would you prefer to use SQL or LDAP or something else?
>
> There are many example configuration files in the "goodies" directory 
> of the Radiator 3.17.1 distribution.
>
I'd prefer to use MySQL, but it seemed like a nightmare with FreeRadius.

A previous employer of mine used Radiator, so i thought it might be
worth looking to see if Radiator could do what we want somewhat more
sanely.

I initially have 2 basic type of account, a standard internet account
and an account which gives access to a VRF.

First, the internet service has two types, static and dynamic, i'm sure
this is nothing special :)

Dynamic like :

test at vostron.net     User-Password == "testing"
        Tunnel-Type = L2TP,
        Tunnel-Medium-Type = IP,
        Tunnel-Password = BLAH,
        Tunnel-Server-Endpoint = x.x.x.x,
        Tunnel-Client-Auth-ID = BLAH,
        Service-Type = Framed-User,
        Framed-Protocol = PPP

and static the same with the addition of IP details

        Framed-IP-Address = 89.21.240.0,
        Framed-IP-Netmask = 255.255.255.255,

Is there a way radiator could generate these additions of a particular
field in the database has a CIDR block in it or something?

It's also possible that static customers could have one or more
additional subnets routed to them, which would require cisco avpairs. 
Are there any best practices on handling that?

VRF access accounts are a bit more complicated, and need two extra
cisco-avpairs to put them in the right vrf and give them the correct ip
unnumbered interface like this :

blah at mpls.vostron.net  User-Password == "blah"
        Tunnel-Type = L2TP,
        Tunnel-Medium-Type = IP,
        Tunnel-Password = blah,
        Tunnel-Server-Endpoint = x.x.x.x,
        Tunnel-Client-Auth-ID = BLAH,
        Service-Type = Framed-User,
        Framed-Protocol = PPP,
        Framed-IP-Address = 10.255.254.1,
        Framed-IP-Netmask = 255.255.255.255,
        Cisco-AVPair = "ip:dns-servers=10.10.0.1",
        Cisco-AVPair += "ip:route=10.255.254.1 255.255.255.255",
        Cisco-AVPair += "ip:route#1=10.1.0.0 255.255.0.0",
        Cisco-AVPair += "ip:route#2=10.0.0.0 255.0.0.0",
        Cisco-AVPair += "lcp:interface-config=ip vrf forwarding
XXXXXXXX",
        Cisco-AVPair += "lcp:interface-config=ip unnumbered loopback
60001"

These accounts can also have a bunch of extra routes, as they're often
used to provide backup to a private leased line.

The final thing i want to be able to do (that i can remember!) is to
pool our LNSes. For example, static and dynamic customers could get
assigned lns 1.1.1.1 1.1.1.2 or 1.1.1.3 in a round-robin fashion, but i
need to be able to lock vrf accounts to one or maybe two LNSes
(otherwise every VRF has to be present on every LNS, which is a pain!)

I'm basically just looking for a sane database schema and radiator
config setup to handle this. An existing management interface would be
ace, but I doubt any exist, and i'll probably end up writing one
anyways!

Kind Regards,
Adam Armstrong
Vostron Limited

> On 14 Aug 2007, at 10:05, Adam Armstrong wrote:
>
>> Hi,
>>
>> I'm trying to sort out an authentication for our L2TP ADSL delivery 
>> to replace the current FreeRadius + Flat Files mess.
>>
>> Are there any front-ends out there which handle this stuff nicely? I 
>> also need to pass the occasional extra Cisco-AVPair (for clients in 
>> other VRFs).
>>
>> Any example Radiator configs or pointers to some decent documentation

>> would be great!
>>
>> Thanks,
>> adam.
>>
>> --
>> Archive at http://www.open.com.au/archives/radiator/
>> Announcements on radiator-announce at open.com.au To unsubscribe, email 
>> 'majordomo at open.com.au' with 'unsubscribe radiator' in the body of 
>> the message.
>
>
>
> NB:
>
> Have you read the reference manual ("doc/ref.html")?
> Have you searched the mailing list archive 
> (www.open.com.au/archives/radiator)?
> Have you had a quick look on Google (www.google.com)?
> Have you included a copy of your configuration file (no secrets), 
> together with a trace 4 debug showing what is happening?
> Have you checked the RadiusExpert wiki:
> http://www.open.com.au/wiki/index.php/Main_Page
>

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au To unsubscribe, email
'majordomo at open.com.au' with 'unsubscribe radiator' in the body of the
message.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.


More information about the radiator mailing list