(RADIATOR) DSL Auth setup

Adam Armstrong lists at memetic.org
Wed Aug 15 06:21:27 CDT 2007


Hi Hugh,

Thanks for the examples, i spent quite a while last night looking at the 
things in goodies/. It's probably going to be quite a bit mroe involved 
than i had hoped getting this all setup correctly!

I really wish i could spent the cash on paying someone else on setting 
it all up, but it's hard enough getting the cash to actually pay for 
radiator! ;)

The last thing I'm struggling with is accounting. I know how to set 
everything up to account to files or sql, but what i cant' work out is 
how to do per-hour accounting.

I'm guessing it's either something really obvious that i've missed, or 
just impossible due to the way radius works?

For example, i want to be able to calculate the bandwidth usage for a 
client between the hours of 0800 - 0000, when it's entirely possible 
that their session will stay up for months at a time. I've currently got 
the server kicking out radius accounting updates every 15 minutes, but 
they seem to be rolling updates? is it possible to get a just the amount 
transferred in the last 15 minutes?

Thanks,
adam.
>
> Hello Adam -
>
> We have many customers who use MySQL very successfully, and all of our 
> SQL examples in the Radiator distrubution also use MySQL.
>
> There is script to set up the example MySQL schema in 
> "goodies/mysqlCreate.sql".
>
> In my consulting practice I generally tend to organise things around 
> functional groups based on Client clause(s) with Identifier(s).
>
> Something like this:
>
> ......
>
> # define Client clauses with Identifiers
>
> <Client 1.1.1.1>
>     Identifier SomethingMeaningful
>     .....
> </Client>
>
> <Client 2.2.2.2>
>     Identifier SomethingMeaningful
>     .....
> </Client>
>
> <Client 3.3.3.3>
>     Identifier AnotherUsefulTag
>     .....
> </Client>
>
> <Client 4.4.4.4>
>     Identifier AnotherUsefulTag
>     .....
> </Client>
>
> ......
>
> # define AuthBy clause(s) with Identfier(s)
>
> <AuthBy SQL>
>     Identifier CheckDatabase
>     ......
>     AuthSelect select PASSWORD, CHECKATTR, REPLYATTR \
>         from SUBSCRIBERS \
>         where USERNAME = %0
>     AuthColumnDef 0, Password, check
>     AuthColumnDef 1, GENERIC, check
>     AuthColumnDef 2, GENERIC, reply
>     ......
>     # add common reply attributes
>     AddToReply ......
>     ......
> </AuthBy>
>
> ......
>
> # define Handlers
>
> <Handler Client-Identifier = SomethingMeaningful>
>
>     <AuthBy GROUP>
>        
>         AuthBy CheckDatabase
>
>         AddToReply ......
>
>     </AuthBy>
>
> </Handler>
>
> <Handler Client-Identifier = AnotherUsefulTag>
>
>     <AuthBy GROUP>
>        
>         AuthBy CheckDatabase
>
>         AddToReply ......
>
>     </AuthBy>
>
> </Handler>
>
> .......
>     
>     
> Groups of reply attributes for a single user can all be specified in 
> the field called "REPLYATTR" in the database.
>
> All of the common reply attributes can be specified in the AddToReply 
> in the AuthBy SQL clause, and reply attributes that depend on each 
> Handler can be specified in the AddToReply in the AuthBy GROUP.
>
> See section 5.29 in the Radiator 3.17.1 reference manual 
> ("doc/ref.html").
>
> BTW - we are available on a contract basis for design, implementation 
> and training as required.
>
> regards
>
> Hugh
>
>
>
> On 14 Aug 2007, at 21:00, Adam Armstrong wrote:
>
>> 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.
>
>
>
> 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.


More information about the radiator mailing list