Re: suggestions for multiple vlans in hundreds of switches
Arran Cudbard-Bell wrote: > I didn't know freeradius supported bitwise operators ! They're not > listed anywhere so I assumed you couldn't use them ?! It doesn't support them. But it shouldn't be too hard to add. In the CVS head, I'm doing some large cleanups to make features like this much easier. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
Phil Mayers wrote: > Except if you're using plain EAP-TLS where there's no inner tunnel IIRC? Yes. > I have wondered where it might be sensible to fake a PAP request with > the certificate details for EAP-TLS. This would provide (I think) quite > a good way for people to do certificate checking and logging etc. It's not a bad idea. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
Phil Mayers wrote:
> Arran Cudbard-Bell wrote:
>
>>> This could also be done cleaner (but slower) with cleverly designed SQL
>>> tables or stored procedures
>>>
>>>
>> Yeah, complex sql really can be quite slow, specially when the queries
>> are being run multiple times for all the rounds required in eap
>> authentication.
>>
>
>
> You've seen Alans hint re: only running on the tunnel so that helps there.
>
>
>> I use a second instance of preprocess to read a second hints file called
>> 'nas_hints' this uses dynamic sql queries to grab extra nas_attributes
>> from the server.
>>
>
> That's a clever trick.
>
> One of the main advantages of the rlm_passwd module is that it can add
> items to the *request* as well as the config and reply items. It would
> be extremely handy if the SQL module could do this too.
>
> Specifically I can think of uses for 2-pass SQL queries where one would
> want to use data returned from the 1st query in the 2nd. This is
> basically impossible to do without using stored procedures at the moment.
>
> Regarding your bitmask trick - maybe there's a use for bitwise
> operators, e.g.:
>
> # NAS-Features - integer bitfield
> # 128 - router, admins only
> # 64 - do vlan assignment
> # 32 - do IP assignment
>
> DEFAULT NAS-Features & 128, SQL-Group != "ADMINS", Auth-Type := Reject
> Reply-Message = "admins only"
>
> DEFAULT NAS-Features & 64
> Tunnel-Private-Group-Id = `%{sql:select vlan('%{NAS-IP-Address}',
> '%{User-Name}')}`
> Fall-Through = Yes
>
> DEFAULT NAS-Features & 32, Pool-Name := "something"
>
> ...and so on
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
Yes !!!
I didn't know freeradius supported bitwise operators ! They're not
listed anywhere so I assumed you couldn't use them ?!
Ohh this makes things so much neater :)
Thanks Phil
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
Arran Cudbard-Bell wrote: > > Wow this is going to speed stuff up so much ! We use this trick extensively. It works really well. > Ahh yes, I just got how this could work... because to deal with the > contents of the eap tunnel freeradius proxies it to itself... Yes. And if you set "copy_request_to_tunnel = yes" the attributes from the real packet get copied to the tunneled one - e.g. NAS-IP-Address, NAS-Port, etc. so you can still act on those attributes. > And though your only writing the reply attributes to the tunnel , when > the tunneled request comes back, > the attributes will be used in the main packet sent back to the NAS, > including the eap message from the proxied request ... Provided you have "use_tunneled_reply = yes" > > Is the proxying to self new behaviour ? No > > I know the Authz-Type and Auth-Type stuff is only in CVS so you must not > have been able to do it in 1.1* ? Erm, no. They've been around a long time. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
Alan DeKok wrote: > Arran Cudbard-Bell wrote: > >> Yeah, complex sql really can be quite slow, specially when the queries >> are being run multiple times for all the rounds required in eap >> authentication. > > If you're using the TLS variants of EAP, you can do: Except if you're using plain EAP-TLS where there's no inner tunnel IIRC? I have wondered where it might be sensible to fake a PAP request with the certificate details for EAP-TLS. This would provide (I think) quite a good way for people to do certificate checking and logging etc. User-Name = "theCN" User-Password = "theCN" FreeRADIUS-Cert-Subject = "cn=theCN,o=Foo,c=GB" FreeRadius-Cert-Issuer = "ou=ICT,o=Foo,c=GB" FreeRADIUS-SubjectAltName = "email:[EMAIL PROTECTED]" FreeRADIUS-SubjectAltName = "email:[EMAIL PROTECTED]" ..etc. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
Arran Cudbard-Bell wrote:
>>
>> This could also be done cleaner (but slower) with cleverly designed SQL
>> tables or stored procedures
>>
> Yeah, complex sql really can be quite slow, specially when the queries
> are being run multiple times for all the rounds required in eap
> authentication.
You've seen Alans hint re: only running on the tunnel so that helps there.
> I use a second instance of preprocess to read a second hints file called
> 'nas_hints' this uses dynamic sql queries to grab extra nas_attributes
> from the server.
That's a clever trick.
One of the main advantages of the rlm_passwd module is that it can add
items to the *request* as well as the config and reply items. It would
be extremely handy if the SQL module could do this too.
Specifically I can think of uses for 2-pass SQL queries where one would
want to use data returned from the 1st query in the 2nd. This is
basically impossible to do without using stored procedures at the moment.
Regarding your bitmask trick - maybe there's a use for bitwise
operators, e.g.:
# NAS-Features - integer bitfield
# 128 - router, admins only
# 64 - do vlan assignment
# 32 - do IP assignment
DEFAULT NAS-Features & 128, SQL-Group != "ADMINS", Auth-Type := Reject
Reply-Message = "admins only"
DEFAULT NAS-Features & 64
Tunnel-Private-Group-Id = `%{sql:select vlan('%{NAS-IP-Address}',
'%{User-Name}')}`
Fall-Through = Yes
DEFAULT NAS-Features & 32, Pool-Name := "something"
...and so on
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
Alan DeKok wrote:
> Arran Cudbard-Bell wrote:
>
>
>> Yeah, complex sql really can be quite slow, specially when the queries
>> are being run multiple times for all the rounds required in eap
>> authentication.
>>
>
> If you're using the TLS variants of EAP, you can do:
>
> DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Autz-Type := "internal"
>
> Then in the "authorize" section, add:
>
> ...
> Autz-Type internal {
> ... do DB lookups here
> }
>
> If you're doing password lookups in LDAP, put "ldap" in that section.
> Then, the LDAP lookups will only be done when they're needed.
>
Yeees, and have a similar one checking for the existence of
User-Password attribute and settings the Autz-Type to LDAP !
Wow this is going to speed stuff up so much !
Thankyou :)
Ahh yes, I just got how this could work... because to deal with the
contents of the eap tunnel freeradius proxies it to itself...
And though your only writing the reply attributes to the tunnel , when
the tunneled request comes back,
the attributes will be used in the main packet sent back to the NAS,
including the eap message from the proxied request ...
Is the proxying to self new behaviour ?
I know the Authz-Type and Auth-Type stuff is only in CVS so you must not
have been able to do it in 1.1* ?
> Alan DeKok.
> --
> http://deployingradius.com - The web site of the book
> http://deployingradius.com/blog/ - The blog
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
Arran Cudbard-Bell wrote:
> Yeah, complex sql really can be quite slow, specially when the queries
> are being run multiple times for all the rounds required in eap
> authentication.
If you're using the TLS variants of EAP, you can do:
DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Autz-Type := "internal"
Then in the "authorize" section, add:
...
Autz-Type internal {
... do DB lookups here
}
If you're doing password lookups in LDAP, put "ldap" in that section.
Then, the LDAP lookups will only be done when they're needed.
Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
Phil Mayers wrote:
> Matt Ashfield wrote:
>
>> Hi,
>>
>> We'd like to use FR to assign users on our wired network to one of 30
>> different vlans on campus, based on an LDAP field. Currently, we are doing
>> this with huntgroups. Namely, we create a huntgroup for the NAS (in our
>> case, a network switch), and then in the users file, we put the following:
>>
>
> Credit to Alan DeKok for this idea - it was one of the first questions I
> asked on the list.
>
> Use two rlm_passwd modules to add "fake" items to the *request*:
>
> passwd nas2building {
>file = /etc/raddb/nas2building
>format = "*NAS-IP-Address:~MyBuilding"
>hashsize = 100
> }
> passwd user2vlantype {
>file = /etc/raddb/user2vlantype
>format = "*User-Name:~MyVlanType"
>hashsize = 100
>allowmultiplekeys = yes
> }
>
> ...then in the users file you reduce NxM to AxB which is a hopefully
> smaller combination:
>
> DEFAULT MyBuilding == "facility1", MyVlanType == "guests"
> ...
> DEFAULT MyBuilding == "facility1", MyVlanType == "staff"
> ...
>
> Note that if you're caching the files, FreeRadius will need to be HUPed
> to re-read them (boo!). Also, you'll need to add the MyXXX attributes to
> the dictionary like so:
>
> ATTRIBUTE MyBuilding 3000string
> ATTRIBUTE MyVlanType 3001string
>
> This could also be done cleaner (but slower) with cleverly designed SQL
> tables or stored procedures
>
Yeah, complex sql really can be quite slow, specially when the queries
are being run multiple times for all the rounds required in eap
authentication.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
I use a second instance of preprocess to read a second hints file called
'nas_hints' this uses dynamic sql queries to grab extra nas_attributes
from the server.
I actually use a really quick and dirty way of getting multiple values
from a very simple query. You store multiple bool vars as a binary
string representation of a 6 digit integer... can then use pattern
matching in group check items to select required values and values you
dont care about.
authorization {
nas_hints
}
preprocess nas_hints {
hints = ${confdir}/nas_hints
}
Here is my nas_hints file
#
# Should speed things up when proxying peap to itself
DEFAULT Packet-Src-IP-Address == localhost
#
# Set the 'PROXY' flag in the feature set for the JRS proxies
DEFAULT Packet-Src-IP-Address == roaming0.ja.net
NAS-Feature-Set = '01001000'
DEFAULT Packet-Src-IP-Address == roaming1.ja.net
NAS-Feature-Set = '01001000'
DEFAULT Packet-Src-IP-Address == roaming2.ja.net
NAS-Feature-Set = '01001000'
#
# Debug entry for home testing.
#DEFAULT Packet-Src-IP-Address == arr-land.co.uk
#NAS-Feature-Set = '01001000'
#
# Retrieve the feature set for all none recognised clients
# from the NetReg3 Database
# Note: Doing the initial pattern match is a far quicker was of doing things
# rather than concatinating the db columns and comparing with client ip !
DEFAULT Packet-Src-IP-Address =~
"^([0-9]+)[.]([0-9]+)[.]([0-9]+)[.]([0-9]+)$"
NAS-Feature-Set = "SELECT
EXPORT_SET(master.nas_flags,'1','0','',20) FROM `master` WHERE ip1 =
'%{1}' AND ip2 = '%{2}' AND ip3 = '%{3}' AND ip4 = '%{4}' LIMIT 0,1"
Heres some group examples...
SQL result
*Host:* localhost
*Database:* radius
*Generation Time:* Apr 20, 2007 at 10:20 PM
*Generated by:* phpMyAdmin 2.9.2 / MySQL 4.1.10a-standard-log
*SQL query:* SELECT * FROM `radgroupcheck` LIMIT 0, 30 ;
*Rows:* 5
id GroupName Attribute op Value
1 nas_admins Service-Type<= NAS-Prompt-User
2 nas_admins Service-Type>= Administrative-User
3 nas_operators Service-Type== NAS-Prompt-User
20 jrs_offsite_ao Huntgroup-Name == jrs-proxy
19 jrs_offsite_ao NAS-Feature-Set =~ 01001000
Heres a fun little php script to take a list of features and produce a
bit string or integer value.
#!/usr/local/php/bin/php
$pad_to)){
$bit_array = array_fill(0,count($flags_def),0);# Create an
array equal to the maximum amount of possible flgs
}else{
$bit_array = array_fill(0,$pad_to,0);# Create an array equal
to pad value, if created than maximum flags
}
foreach($flags as $value){ # For each of
the flags, see if it's value matches one of the keys
if(key_exists($value,$def_flags)){ # If it does then set
that BIT to true
$bit_array[$def_flags[$value]] = 1;
Re: suggestions for multiple vlans in hundreds of switches
Matt Ashfield wrote:
> Hi,
>
> We'd like to use FR to assign users on our wired network to one of 30
> different vlans on campus, based on an LDAP field. Currently, we are doing
> this with huntgroups. Namely, we create a huntgroup for the NAS (in our
> case, a network switch), and then in the users file, we put the following:
Credit to Alan DeKok for this idea - it was one of the first questions I
asked on the list.
Use two rlm_passwd modules to add "fake" items to the *request*:
passwd nas2building {
file = /etc/raddb/nas2building
format = "*NAS-IP-Address:~MyBuilding"
hashsize = 100
}
passwd user2vlantype {
file = /etc/raddb/user2vlantype
format = "*User-Name:~MyVlanType"
hashsize = 100
allowmultiplekeys = yes
}
...then in the users file you reduce NxM to AxB which is a hopefully
smaller combination:
DEFAULT MyBuilding == "facility1", MyVlanType == "guests"
...
DEFAULT MyBuilding == "facility1", MyVlanType == "staff"
...
Note that if you're caching the files, FreeRadius will need to be HUPed
to re-read them (boo!). Also, you'll need to add the MyXXX attributes to
the dictionary like so:
ATTRIBUTE MyBuilding 3000string
ATTRIBUTE MyVlanType 3001string
This could also be done cleaner (but slower) with cleverly designed SQL
tables or stored procedures
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
Hi,
> This seems to work. The issue is scale. I have would conceivably have to
> have a huntgroup definition in the huntgroups file for each NAS. And if I
> wanted 30 vlans, I'd have to have 30 definitions like the ones above in my
> users file for EACH one of my NAS's.
that would depend on what scale this would have to go to. certainly
if each switch were to hav different VLANs for each of the types of users
eg switch 1 vlan 200 for staff, vlan 201 for researchers
switch 2 vlan 300 for staff, vlan 301 for researchers
this woul dget very big very quickly.
however, if each switch only needs to feed the same VLAN depending
on the class of user - ie those 30 VLANs are are the same on each switch,
then you can simply define a normal huntgroup for the switch eg in
$place/raddb/huntgroup
my-switches NAS-IP-Address == 231.123.241.123
my-switches NAS-IP-Address == 231.123.241.124
my-switches NAS-IP-Address == 231.123.241.125
my-switches NAS-IP-Address == 231.123.241.126
etc etc.
then, in your example , the entry looks like
DEFAULT Huntgroup-Name == my-switches, Ldap-Group == student
User-Name=`%{User-Name}`,
Tunnel-Private-Group-Id=177,
Tunnel-Type=VLAN,
Fall-Through = no
(plus the others for each class of user)
a 'clear scale' way would otherwise to be having an SQL table which defines
each VLAN for each Ldap-group for each switch (or NAS) and use Perl
or python to extract that info and return the attributes based on
the request.
alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: suggestions for multiple vlans in hundreds of switches
Yeah, there's that too. We need to create these vlans within the edge
switches as well. Once created, you shouldn't have to touch them again.
Or you don't create them at the edge, and instead just create them in the
core, however that kind of kills the advantage of extending your vlans to
the edge.
Matt Ashfield
Network Analyst
Integrated Technology Services
University of New Brunswick
(506) 447-3033
[EMAIL PROTECTED]
-Original Message-
From: robinson santos [mailto:[EMAIL PROTECTED]
Sent: April 19, 2007 12:31 PM
To: [EMAIL PROTECTED]; FreeRadius users mailing list
Subject: Re: suggestions for multiple vlans in hundreds of switches
Matt, how about the configuration that you have to have in the switch
Can you Help me
Robinson
[EMAIL PROTECTED]
On 4/19/07, Matt Ashfield <[EMAIL PROTECTED]> wrote:
Hi,
We'd like to use FR to assign users on our wired network to one of 30
different vlans on campus, based on an LDAP field. Currently, we are doing
this with huntgroups. Namely, we create a huntgroup for the NAS (in our
case, a network switch), and then in the users file, we put the following:
DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == staff
User-Name=`%{User-Name}`,
Tunnel-Private-Group-Id=176,
Tunnel-Type=VLAN,
Fall-Through = no
DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == student
User-Name=`%{User-Name}`,
Tunnel-Private-Group-Id=177,
Tunnel-Type=VLAN,
Fall-Through = no
And so on...for other groups of user like faculty, admin, etc..
This seems to work. The issue is scale. I have would conceivably have to
have a huntgroup definition in the huntgroups file for each NAS. And if I
wanted 30 vlans, I'd have to have 30 definitions like the ones above in my
users file for EACH one of my NAS's.
I'm sure there's a simpler way of doing things that I'm missing. Any advice
is appreciated.
Thanks
Matt
[EMAIL PROTECTED]
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: suggestions for multiple vlans in hundreds of switches
I was afraid someone would say that! Haha
Matt
-Original Message-
From: Donny Jekels [mailto:[EMAIL PROTECTED]
Sent: April 19, 2007 10:57 AM
To: [EMAIL PROTECTED]; FreeRadius users mailing list
Subject: Re: suggestions for multiple vlans in hundreds of switches
you could extend your ldap schema and add a field for the vlan a user should
belong too.
then all you would need is to query that field and propogate the variable.
"Tunnel-Private-Group-Id=`%{private-vlan}`"
On 4/19/07, Matt Ashfield <[EMAIL PROTECTED]> wrote:
Hi,
We'd like to use FR to assign users on our wired network to one of 30
different vlans on campus, based on an LDAP field. Currently, we are doing
this with huntgroups. Namely, we create a huntgroup for the NAS (in our
case, a network switch), and then in the users file, we put the following:
DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == staff
User-Name=`%{User-Name}`,
Tunnel-Private-Group-Id=176,
Tunnel-Type=VLAN,
Fall-Through = no
DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == student
User-Name=`%{User-Name}`,
Tunnel-Private-Group-Id=177,
Tunnel-Type=VLAN,
Fall-Through = no
And so on...for other groups of user like faculty, admin, etc..
This seems to work. The issue is scale. I have would conceivably have to
have a huntgroup definition in the huntgroups file for each NAS. And if I
wanted 30 vlans, I'd have to have 30 definitions like the ones above in my
users file for EACH one of my NAS's.
I'm sure there's a simpler way of doing things that I'm missing. Any advice
is appreciated.
Thanks
Matt
[EMAIL PROTECTED]
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
Matt, how about the configuration that you have to have in the switch
Can you Help me
Robinson
[EMAIL PROTECTED]
On 4/19/07, Matt Ashfield <[EMAIL PROTECTED]> wrote:
Hi,
We'd like to use FR to assign users on our wired network to one of 30
different vlans on campus, based on an LDAP field. Currently, we are doing
this with huntgroups. Namely, we create a huntgroup for the NAS (in our
case, a network switch), and then in the users file, we put the following:
DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == staff
User-Name=`%{User-Name}`,
Tunnel-Private-Group-Id=176,
Tunnel-Type=VLAN,
Fall-Through = no
DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == student
User-Name=`%{User-Name}`,
Tunnel-Private-Group-Id=177,
Tunnel-Type=VLAN,
Fall-Through = no
And so on...for other groups of user like faculty, admin, etc..
This seems to work. The issue is scale. I have would conceivably have to
have a huntgroup definition in the huntgroups file for each NAS. And if I
wanted 30 vlans, I'd have to have 30 definitions like the ones above in my
users file for EACH one of my NAS's.
I'm sure there's a simpler way of doing things that I'm missing. Any
advice
is appreciated.
Thanks
Matt
[EMAIL PROTECTED]
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: suggestions for multiple vlans in hundreds of switches
you could extend your ldap schema and add a field for the vlan a user should
belong too.
then all you would need is to query that field and propogate the variable.
"Tunnel-Private-Group-Id=`%{private-vlan}`"
On 4/19/07, Matt Ashfield <[EMAIL PROTECTED]> wrote:
Hi,
We'd like to use FR to assign users on our wired network to one of 30
different vlans on campus, based on an LDAP field. Currently, we are doing
this with huntgroups. Namely, we create a huntgroup for the NAS (in our
case, a network switch), and then in the users file, we put the following:
DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == staff
User-Name=`%{User-Name}`,
Tunnel-Private-Group-Id=176,
Tunnel-Type=VLAN,
Fall-Through = no
DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == student
User-Name=`%{User-Name}`,
Tunnel-Private-Group-Id=177,
Tunnel-Type=VLAN,
Fall-Through = no
And so on...for other groups of user like faculty, admin, etc..
This seems to work. The issue is scale. I have would conceivably have to
have a huntgroup definition in the huntgroups file for each NAS. And if I
wanted 30 vlans, I'd have to have 30 definitions like the ones above in my
users file for EACH one of my NAS's.
I'm sure there's a simpler way of doing things that I'm missing. Any
advice
is appreciated.
Thanks
Matt
[EMAIL PROTECTED]
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
suggestions for multiple vlans in hundreds of switches
Hi,
We'd like to use FR to assign users on our wired network to one of 30
different vlans on campus, based on an LDAP field. Currently, we are doing
this with huntgroups. Namely, we create a huntgroup for the NAS (in our
case, a network switch), and then in the users file, we put the following:
DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == staff
User-Name=`%{User-Name}`,
Tunnel-Private-Group-Id=176,
Tunnel-Type=VLAN,
Fall-Through = no
DEFAULT Huntgroup-Name == mySWITCH1, Ldap-Group == student
User-Name=`%{User-Name}`,
Tunnel-Private-Group-Id=177,
Tunnel-Type=VLAN,
Fall-Through = no
And so on...for other groups of user like faculty, admin, etc..
This seems to work. The issue is scale. I have would conceivably have to
have a huntgroup definition in the huntgroups file for each NAS. And if I
wanted 30 vlans, I'd have to have 30 definitions like the ones above in my
users file for EACH one of my NAS's.
I'm sure there's a simpler way of doing things that I'm missing. Any advice
is appreciated.
Thanks
Matt
[EMAIL PROTECTED]
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
