Huntgroups with NAS-Port-Id or NAS-Port
Hello, In my huntgroups file I would like to split a switch into 2 different huntgroups. I found out this would be possible using the NAS-Port-ID option and then selecting a range of ports, at least that is what the documentation in the file states. Testing this, I thing I see the following: A client detail record looks like this: Fri Oct 18 13:59:28 2019 Packet-Type = Access-Request NAS-IP-Address = 192.168.203.126 Fabric-Attach-Switch-Mode = 2 Attr-26.562.183 = 0x00000000 NAS-Port-Type = Ethernet NAS-Port-Id = "3/1" Service-Type = Framed-User Message-Authenticator = 0x....................... Called-Station-Id = "A4-25-1B-C9-6C-01" NAS-Port = 257 Framed-MTU = 1490 User-Name = "av140bbpoe20" Calling-Station-Id = "00-AA-6E-30-73-69" State = 0x............................. EAP-Message = 0x........................................... Event-Timestamp = "Oct 18 2019 13:59:28 CEST" Huntgroup-Name = "ers5900core" Timestamp = 1571399968 As you can see: the NAS-Port-Id looks like a Cisco port number with blade/port. the NAS-Port looks like the number of the port in the stack. When I try to put NAS-Port in the huntgroup name I can't seem to define a range, and if I use the NAS-Port-Id and put the number values of NAS-Port in it as a range it is not recognized. If I put the value "3/1" in the huntgroup definition it seems to work, but then I have to create 192 huntgroup lines. What is the correct solution to fix this? Thanks, Jan Hugo Prins
On Oct 18, 2019, at 8:25 AM, Jan Hugo Prins <jhp@jhprins.org> wrote:
As you can see: the NAS-Port-Id looks like a Cisco port number with blade/port. the NAS-Port looks like the number of the port in the stack.
That's common.
When I try to put NAS-Port in the huntgroup name I can't seem to define a range,
Ranges aren't supported in v3.
and if I use the NAS-Port-Id and put the number values of NAS-Port in it as a range it is not recognized.
What does that mean?
If I put the value "3/1" in the huntgroup definition it seems to work, but then I have to create 192 huntgroup lines.
What is the correct solution to fix this?
Don't use huntgroups. Use "unlang" if (NAS-Port > 15 && NAS-Port < 32 && NAS-Port-Id == "3/1") { ... } Alan DeKok.
In the past I created something to update some variables in the request for some corner cases. Is this what I should do here as well? Create a policy that is something like: update_NAS_Port_Id { if (NAS-IP-Address == "192.168.203.126") { update request { &NAS-Port-Id := "%{request:NAS-Port}" } updated } And include this policy in the authorize section of my config? Jan Hugo Prins On 10/18/19 3:00 PM, Alan DeKok wrote:
On Oct 18, 2019, at 8:25 AM, Jan Hugo Prins <jhp@jhprins.org> wrote:
As you can see: the NAS-Port-Id looks like a Cisco port number with blade/port. the NAS-Port looks like the number of the port in the stack. That's common.
When I try to put NAS-Port in the huntgroup name I can't seem to define a range, Ranges aren't supported in v3.
and if I use the NAS-Port-Id and put the number values of NAS-Port in it as a range it is not recognized. What does that mean?
If I put the value "3/1" in the huntgroup definition it seems to work, but then I have to create 192 huntgroup lines.
What is the correct solution to fix this? Don't use huntgroups. Use "unlang"
if (NAS-Port > 15 && NAS-Port < 32 && NAS-Port-Id == "3/1") { ... }
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Oct 18, 2019, at 9:52 AM, Jan Hugo Prins <jhp@jhprins.org> wrote:
In the past I created something to update some variables in the request for some corner cases. Is this what I should do here as well?
To do what?
Create a policy that is something like:
update_NAS_Port_Id { if (NAS-IP-Address == "192.168.203.126") { update request { &NAS-Port-Id := "%{request:NAS-Port}" } updated }
And include this policy in the authorize section of my config?
Why? What is the goal? Alan DeKok.
What I want to do is differentiate in what to send to a users based on his authentication and huntgroup. This works fine, except for the fact that I can't select the proper huntgroup at the moment on this specific NAS because I need to differentiate on the port the client is connected on. What I could do, is update the huntgroup in the auth-detail using a policy with unlang: update_Huntgroup { if (huntgroup == "ers5900" and NAS-Port == "3/1") { update request { &huntgroup := "ers5900edge" } updated } } But then I also have to create a whole lot of code to make the correct decisions. Better just fill the huntgroup file with enough lines to make the correct decision. Jan Hugo My goal is to differentiate between ports where the user On 10/18/19 4:06 PM, Alan DeKok wrote:
On Oct 18, 2019, at 9:52 AM, Jan Hugo Prins <jhp@jhprins.org> wrote:
In the past I created something to update some variables in the request for some corner cases. Is this what I should do here as well? To do what?
Create a policy that is something like:
update_NAS_Port_Id { if (NAS-IP-Address == "192.168.203.126") { update request { &NAS-Port-Id := "%{request:NAS-Port}" } updated }
And include this policy in the authorize section of my config? Why? What is the goal?
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Oct 18, 2019, at 11:13 AM, Jan Hugo Prins <jhp@jhprins.org> wrote:
What I want to do is differentiate in what to send to a users based on his authentication and huntgroup.
No. What I'm saying is that huntgroups are the wrong solution. The huntgroup functionality is limited. It doesn't have the full expressive power of generic unlang statements.
This works fine, except for the fact that I can't select the proper huntgroup at the moment on this specific NAS because I need to differentiate on the port the client is connected on. What I could do, is update the huntgroup in the auth-detail using a policy with unlang:
update_Huntgroup { if (huntgroup == "ers5900" and NAS-Port == "3/1") { update request { &huntgroup := "ers5900edge"
No. You can't change the Huntrgoup attribute. It is defined to work with the huntgroup file.
But then I also have to create a whole lot of code to make the correct decisions. Better just fill the huntgroup file with enough lines to make the correct decision.
That makes no sense. Why not just do something simpler? Edit raddb/dictionary to create a string attribute "My-Policy". Then write rules in unlang, instead of in the huntgroup file: if (NAS-Port > 15 && NAS-Port < 32) { update request { My-Policy := "foo" } } And then check the My-Policy attribute later. There is nothing which *forces* you to use huntgroups. The server has multiple methods of creating policies for this reason. If huntgroups aren't the right approach, use something else. Don't try to force the subject. You're trying to hammer a round peg into a square hole. Don't do that. Alan DeKok.
participants (2)
-
Alan DeKok -
Jan Hugo Prins