Multiple NAS ips in home_server for COA packets
Dear to All, First of all, thanks for this amazing software! I'm trying to implement in my setup (currently a 3.0.17 freeradius) some logic to change the authorization of some clients connected to some access points creating COA Request packet in response to the accounting received from the access points. I've managed to create the logic based on the example I've found in the originate-coa virtual site that sends the coa packet if a particular condition is met. Here's a piece of the configuration inside the accounting {} area of the virtual host I'm using for the testing: if(Ldap-Group == "InternetAccess" || Ldap-Group == "TEACHER") { if(Extreme-User-Profile-Attribute == "4") { update coa { &User-Name = "%{User-Name}" &Acct-Session-Id = "%{Acct-Session-Id}" &NAS-IP-Address = "%{NAS-IP-Address}" Filter-Id = 2 } } } It works and it effectively prepare the packet, but in order to make it fully work, I had to create a home_server that correspond to the access points (NAS) I'm using for testing like this: home_server wifi_test_coa { type = coa ipaddr = x.x.x.x port = 3799 secret = xxxxxxx # CoA specific parameters. See raddb/proxy.conf for details. coa { irt = 2 mrt = 16 mrc = 5 mrd = 30 } } Now I need to deploy that configuration to all my access points, that are around 150, and making 150 home_server configurations, one for every NAS, it's really long and error prone. Is There's any way I can specify a home_server that represents all those access points? I've tried to set the "ipaddr" to a full ip class, like I've done in the client section, but it doesn't seem to accept a class of that size (it only accepts a /32 address). Any work around? Thanks to all Cheers Daniele -- <https://www.salesianisesto.it/> <https://www.google.it/maps/place/Opere+Sociali+Don+Bosco+-+Salesiani+Sesto/@45.5435274,9.2283012,17z/> <https://www.facebook.com/osdbsesto> <https://www.youtube.com/user/salesianisesto> <https://twitter.com/salesianisesto> <https://www.instagram.com/salesianisesto/>
Daniele Mantovani <dmantovani@salesianisesto.it>:
Now I need to deploy that configuration to all my access points, that are around 150, and making 150 home_server configurations, one for every NAS, it's really long and error prone. Is There's any way I can specify a home_server that represents all those access points?
That's been a longstanding limitation of originate_coa. In many deployments a common secret is not used and the NAS data is taken from a flat file or database. IIRC there may be support for doing corresponding home server definitions like this. Possibly this will be enhanced in FreeRADIUS4 since ISTR talk of a dynamic home server mechanism and this feature could potentially be a beneficiary of that. It is indeed a pain to have to sync up records on other systems every time you add move or change a NAS when you have hundreds of them. If you have the time to tool that into your NAS onboarding procedure it's a lot less painful, but then you have to maintain that tooling over the long term. Note that, depending on the NAS, CoA can often use a different secret and/or be entirely different servers than the one that took the auth+acct, as long as they get the session ID from accounting. So there are two workaround options: generate the CoA from a shelled out script instead, or relay to a 3rd party product which can usually send CoAs directly to the NAS. (If this is HPEAruba, there's a special nuanced trick to that.) -- <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.salesianisesto.it%2F&data=04%7C01%7Cbjulin%40clarku.edu%7Cf07ce4b7afa24ec16ec108da18a267d7%7Cb5b2263d68aa453eb972aa1421410f80%7C0%7C0%7C637849383063446209%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9HZUsv96QwC8nDbKrBkL3t0vVXlSUheiG0HCts9Fm7w%3D&reserved=0> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.it%2Fmaps%2Fplace%2FOpere%2BSociali%2BDon%2BBosco%2B-%2BSalesiani%2BSesto%2F%4045.5435274%2C9.2283012%2C17z%2F&data=04%7C01%7Cbjulin%40clarku.edu%7Cf07ce4b7afa24ec16ec108da18a267d7%7Cb5b2263d68aa453eb972aa1421410f80%7C0%7C0%7C637849383063446209%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FqYcrguiqEDAROS5jrkaC3u0E12jYdNdu50GlM4%2BQbs%3D&reserved=0> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2Fosdbsesto&data=04%7C01%7Cbjulin%40clarku.edu%7Cf07ce4b7afa24ec16ec108da18a267d7%7Cb5b2263d68aa453eb972aa1421410f80%7C0%7C0%7C637849383063446209%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3R4SW7PWLpxU4R%2BFlSWNQPWARBG0Y3%2Brs58Ff26P9Ak%3D&reserved=0> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fuser%2Fsalesianisesto&data=04%7C01%7Cbjulin%40clarku.edu%7Cf07ce4b7afa24ec16ec108da18a267d7%7Cb5b2263d68aa453eb972aa1421410f80%7C0%7C0%7C637849383063446209%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JEdQ%2FBcWqsMGlqu7Weun2GdobyrFUy66i2KGIo%2FGVok%3D&reserved=0> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fsalesianisesto&data=04%7C01%7Cbjulin%40clarku.edu%7Cf07ce4b7afa24ec16ec108da18a267d7%7Cb5b2263d68aa453eb972aa1421410f80%7C0%7C0%7C637849383063602439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MlATOoXRTe6HGZtq54LqmS8qJUFrRPdNNkyEk07SXqM%3D&reserved=0> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.instagram.com%2Fsalesianisesto%2F&data=04%7C01%7Cbjulin%40clarku.edu%7Cf07ce4b7afa24ec16ec108da18a267d7%7Cb5b2263d68aa453eb972aa1421410f80%7C0%7C0%7C637849383063602439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EAwJCdi%2B3fv1QbmYJsumerESCEhZthqlsfq7UUkEviA%3D&reserved=0> - List info/subscribe/unsubscribe? See https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeradius.org%2Flist%2Fusers.html&data=04%7C01%7Cbjulin%40clarku.edu%7Cf07ce4b7afa24ec16ec108da18a267d7%7Cb5b2263d68aa453eb972aa1421410f80%7C0%7C0%7C637849383063602439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=RNcEUb5i2%2BrvZVDRyxD%2BaiuNKTz4gnyaYjYZ7lH0usg%3D&reserved=0
On Apr 7, 2022, at 10:58 AM, Brian Julin <BJulin@clarku.edu> wrote:
That's been a longstanding limitation of originate_coa. In many deployments a common secret is not used and the NAS data is taken from a flat file or database. IIRC there may be support for doing corresponding home server definitions like this. Possibly this will be enhanced in FreeRADIUS4 since ISTR talk of a dynamic home server mechanism and this feature could potentially be a beneficiary of that.
Given that we have 3.2.x now, it would be useful to add *small* changes to support this functionality. Even allowing a network/mask for CoA "home_server" definitions would help a lot. Allowing for custom shared secrets would be harder, unfortunately.
It is indeed a pain to have to sync up records on other systems every time you add move or change a NAS when you have hundreds of them. If you have the time to tool that into your NAS onboarding procedure it's a lot less painful, but then you have to maintain that tooling over the long term.
It's likely not too hard to add functionality which gets the "CoA" fields from SQL. That just has to have a schema / queries defined, and maybe 100 lines of code.
Note that, depending on the NAS, CoA can often use a different secret and/or be entirely different servers than the one that took the auth+acct, as long as they get the session ID from accounting. So there are two workaround options: generate the CoA from a shelled out script instead, or relay to a 3rd party product which can usually send CoAs directly to the NAS. (If this is HPEAruba, there's a special nuanced trick to that.)
See also sites-available/coa-relay, which makes it much easier to send coa / disconnect packets to a NAS. You don't even need to know where the user is, the virtual server figures it out. Alan DeKok.
Many Thanks to both of you! I hoped there's some sort of workaround, but I can understand why this is done this way.
Given that we have 3.2.x now, it would be useful to add *small* changes to support this functionality. Even allowing a network/mask for CoA "home_server" definitions would help a lot.
I wish in some future version there will be something like this! I can think of many situations where you have to reply back to a group of NAS and all have the same "parameters" and are in the same network class. Maybe that type of home_server that can have a network class as a network address can be "flagged" in some particular way that prevents it from being used to proxy other types of requests and only be used to resolve the coa packet send. In case, if you need a beta tester, I'm in ;)
I'm trying to implement in my setup (currently a 3.0.17 freeradius) I suggest upgrading, but whatever.
I'm planning to do that during the summer break. I've many configurations to migrate to the new 4.0 syntax, and it will take some time ;)
Now I need to deploy that configuration to all my access points, that are around 150, and making 150 home_server configurations, one for every NAS, it's really long and error prone.
Create them from templates.
Thanks for the suggestion. I would probably try to go this way at the moment, generating with a script a file to be included in the proxy.conf file, with the list of the NAS that all reference the same template. The only downside of this way is that every time I need to change a NAS, I need to re-run that script and reload/restart my freeradius instances. Maybe the mysql configuration way could be useful in this case. Thanks again! Cheers Daniele -- <https://www.salesianisesto.it/> <https://www.google.it/maps/place/Opere+Sociali+Don+Bosco+-+Salesiani+Sesto/@45.5435274,9.2283012,17z/> <https://www.facebook.com/osdbsesto> <https://www.youtube.com/user/salesianisesto> <https://twitter.com/salesianisesto> <https://www.instagram.com/salesianisesto/>
On Apr 7, 2022, at 10:24 AM, Daniele Mantovani <dmantovani@salesianisesto.it> wrote:
First of all, thanks for this amazing software!
Thanks! We try. :)
I'm trying to implement in my setup (currently a 3.0.17 freeradius)
I suggest upgrading, but whatever.
It works and it effectively prepare the packet, but in order to make it fully work, I had to create a home_server that correspond to the access points (NAS) I'm using for testing like this:
Yes, that works.
Now I need to deploy that configuration to all my access points, that are around 150, and making 150 home_server configurations, one for every NAS, it's really long and error prone.
Create them from templates.
Is There's any way I can specify a home_server that represents all those access points?
Unfortunately, no. RADIUS depends on IP addresses.
I've tried to set the "ipaddr" to a full ip class, like I've done in the client section, but it doesn't seem to accept a class of that size (it only accepts a /32 address).
That's actually a reasonable thing to do. I'll take a look at it for the 3.2.x releases. But in 3.0, you can do this: * edit radiusd.conf, and add the following section before the "security { ... } section templates { nas_template { type = coa port = 3799 secret = xxxx ... anything else from the "home_server" except "ipaddr" } } You can then put this into proxy..conf: home_server foo { ipaddr = 1.2.3.4 $template nas_template } And it will automatically fill in the rest of the fields from the template. See raddb/templates.conf for more documentation. Alan DeKok.
participants (3)
-
Alan DeKok -
Brian Julin -
Daniele Mantovani