Hi, I've been trying to build freeradius from source with the rlm_raw module in the modules folder and adding it to stable. When I run ./configure I can see it gets processed in there, but no matter what I do make just ignores it completely. I've tried make -d to see if maybe there are some errors, but it doesn't report anything in relation to rlm_raw. I was under the impression make was compiling anything in the stable file. I'd like to use the raw module inside the dynamic clients server so I can use mac address or nas-identifier in order to recognise dynamic clients rather the the IP address as per the radiusdesk implementation here https://sourceforge.net/p/radiusdesk/wiki/install_ubuntu_freeradius/#option-... However I would also like to use rlm_rest, so I can't use v2.x.x of freeradius. If anyone is kind enough to answer the following questions or lend some assistance it would be greatly appreciated. 1) Is it possible to get rlm_raw working with 3.1.x? 2) If not is there anyway in v3.1.x that supports this tgype of functionality? Kind Regards Paul
Try 3.0.,x, rlm_rest works nice! Em 06/07/2015 05:23, "Paul Trappitt" <paul@freedomwifi.com.au> escreveu:
Hi,
I've been trying to build freeradius from source with the rlm_raw module in the modules folder and adding it to stable. When I run ./configure I can see it gets processed in there, but no matter what I do make just ignores it completely.
I've tried make -d to see if maybe there are some errors, but it doesn't report anything in relation to rlm_raw. I was under the impression make was compiling anything in the stable file.
I'd like to use the raw module inside the dynamic clients server so I can use mac address or nas-identifier in order to recognise dynamic clients rather the the IP address as per the radiusdesk implementation here
https://sourceforge.net/p/radiusdesk/wiki/install_ubuntu_freeradius/#option-...
However I would also like to use rlm_rest, so I can't use v2.x.x of freeradius.
If anyone is kind enough to answer the following questions or lend some assistance it would be greatly appreciated.
1) Is it possible to get rlm_raw working with 3.1.x? 2) If not is there anyway in v3.1.x that supports this tgype of functionality?
Kind Regards Paul - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Hi Jorge, Thanks for taking the time to reply, much appreciated. Sorry just to confirm, do you mean rlm_raw works with 3.0.x? Cheers Paul On Mon, Jul 6, 2015 at 7:06 PM, Jorge Pereira <jpereiran@gmail.com> wrote:
Try 3.0.,x, rlm_rest works nice! Em 06/07/2015 05:23, "Paul Trappitt" <paul@freedomwifi.com.au> escreveu:
Hi,
I've been trying to build freeradius from source with the rlm_raw module in the modules folder and adding it to stable. When I run ./configure I can see it gets processed in there, but no matter what I do make just ignores it completely.
I've tried make -d to see if maybe there are some errors, but it doesn't report anything in relation to rlm_raw. I was under the impression make was compiling anything in the stable file.
I'd like to use the raw module inside the dynamic clients server so I can use mac address or nas-identifier in order to recognise dynamic clients rather the the IP address as per the radiusdesk implementation here
https://sourceforge.net/p/radiusdesk/wiki/install_ubuntu_freeradius/#option-...
However I would also like to use rlm_rest, so I can't use v2.x.x of freeradius.
If anyone is kind enough to answer the following questions or lend some assistance it would be greatly appreciated.
1) Is it possible to get rlm_raw working with 3.1.x? 2) If not is there anyway in v3.1.x that supports this tgype of functionality?
Kind Regards Paul - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Thanks for taking the time to reply, much appreciated. Sorry just to confirm, do you mean rlm_raw works with 3.0.x?
Try 3.0.,x, rlm_rest works nice!
Yes, use the 3.0.x branch. :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
Great thanks Stefan. Do you know if it is possible to use the rlm_rest module inside the dynamic client server? I'd like to be able to validate my dynamic clients over rest as well if possible and have minimal business logic built in to free radius policies. Cheers Paul On Mon, Jul 6, 2015 at 8:08 PM, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
Thanks for taking the time to reply, much appreciated. Sorry just to confirm, do you mean rlm_raw works with 3.0.x?
Try 3.0.,x, rlm_rest works nice!
Yes, use the 3.0.x branch.
:-)
Stefan Paetow Moonshot Industry & Research Liaison Coordinator
t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet
jisc.ac.uk
Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
I never used mod_raw, i have overlooked... Was about your citation that tried to use rlm_rest in The 2.x. Em 06/07/2015 08:56, "Paul Trappitt" <paul@freedomwifi.com.au> escreveu:
Hi Jorge,
Thanks for taking the time to reply, much appreciated. Sorry just to confirm, do you mean rlm_raw works with 3.0.x?
Cheers
Paul
On Mon, Jul 6, 2015 at 7:06 PM, Jorge Pereira <jpereiran@gmail.com> wrote:
Try 3.0.,x, rlm_rest works nice! Em 06/07/2015 05:23, "Paul Trappitt" <paul@freedomwifi.com.au> escreveu:
Hi,
I've been trying to build freeradius from source with the rlm_raw module in the modules folder and adding it to stable. When I run ./configure I can see it gets processed in there, but no matter what I do make just ignores it completely.
I've tried make -d to see if maybe there are some errors, but it doesn't report anything in relation to rlm_raw. I was under the impression make was compiling anything in the stable file.
I'd like to use the raw module inside the dynamic clients server so I can use mac address or nas-identifier in order to recognise dynamic clients rather the the IP address as per the radiusdesk implementation here
However I would also like to use rlm_rest, so I can't use v2.x.x of freeradius.
If anyone is kind enough to answer the following questions or lend some assistance it would be greatly appreciated.
1) Is it possible to get rlm_raw working with 3.1.x? 2) If not is there anyway in v3.1.x that supports this tgype of functionality?
Kind Regards Paul - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
https://sourceforge.net/p/radiusdesk/wiki/install_ubuntu_freeradius/#option-... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Hi, On Mon, Jul 06, 2015 at 07:56:28PM +0800, Paul Trappitt wrote:
Thanks for taking the time to reply, much appreciated. Sorry just to confirm, do you mean rlm_raw works with 3.0.x?
In case you've missed any previous discussion (this comes up every now and then), you're unlikely to get much support for rlm_raw... http://lists.freeradius.org/pipermail/freeradius-users/2014-August/073292.ht... Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hi Matthew, Thanks, yeah I had found that post. I guess it's not really of much help though. Why is it wrong and what is a valid alternative? Seems as though the dynamic clients module is a bit "cut off at the knees" in a public wifi service provider scenario if all it can access is the src IP address. One alternative is to set the dynamic network to all of the internet so the nas devices don't get blocked and then handle rejections later in the normal policies, but seems like wasted resources to have to process them that far in when they could just be dropped here if they aren't registered devices that could be checked by comparing other fields like nas name or mac etc. Cheers Paul On Mon, Jul 6, 2015 at 8:30 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
Hi,
On Mon, Jul 06, 2015 at 07:56:28PM +0800, Paul Trappitt wrote:
Thanks for taking the time to reply, much appreciated. Sorry just to confirm, do you mean rlm_raw works with 3.0.x?
In case you've missed any previous discussion (this comes up every now and then), you're unlikely to get much support for rlm_raw...
http://lists.freeradius.org/pipermail/freeradius-users/2014-August/073292.ht...
Cheers,
Matthew
-- Matthew Newton, Ph.D. <mcn4@le.ac.uk>
Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk> - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Jul 6, 2015, at 8:37 AM, Paul Trappitt <paul@freedomwifi.com.au> wrote:
Thanks, yeah I had found that post. I guess it's not really of much help though. Why is it wrong and what is a valid alternative? Seems as though the dynamic clients module is a bit "cut off at the knees" in a public wifi service provider scenario if all it can access is the src IP address.
It's about security. The various fields in the packet are just data. Anyone can invent anything, and put the data there. Forging source IPs and having them route across the wider internet is a lot more difficult. If you need random machines to be RADIUS clients, you should use RADIUS over TLS. v3 supports it. You can put a local proxy onto the remote site, and then have that proxy connect to a central server. The central server can then do certificate authentication of the edge machines. Anything else is insecure, and terrible in practice. It doesn't matter if it's convenient. Not using protection is convenient. But the side effects can be grim. If you want to use rlm_raw in v3, go right ahead. But the build system has changed. The internal APIs have changed. You'll have to know C in order to get it working. Alan DeKok.
Hi Alan, Thanks for the response and I fully appreciate your position on it, but personally think it's useful functionality that should be available if someone wants to use it. My only current option to truly allow dynamic clients is to run the dynamic clients with 0.0.0.0/0 which deems it completely insecure anyway. If IP addresses of nas are constantly changing then the IP isn't a value that can be used to securely identify the device anyway so it becomes a bit null and void. We're then left processing the rest of the packet to find the same data we can get from raw and just rejecting the request later down the track. In the scenario of the public wifi service provider (eg something like hotspotsystem, cloud4wi etc), generally the hotspot is running on embedded devices with limited resources so the TLS option and local proxy is just not feasible. Plus it really impacts the "off the shelf" approach to providing such a service. Would just be nice if the option was there for those who want to use it or some alternative that can provide similar functionality then we can. Cheers Paul On Mon, Jul 6, 2015 at 9:05 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 6, 2015, at 8:37 AM, Paul Trappitt <paul@freedomwifi.com.au> wrote:
Thanks, yeah I had found that post. I guess it's not really of much help though. Why is it wrong and what is a valid alternative? Seems as though the dynamic clients module is a bit "cut off at the knees" in a public wifi service provider scenario if all it can access is the src IP address.
It's about security. The various fields in the packet are just data. Anyone can invent anything, and put the data there. Forging source IPs and having them route across the wider internet is a lot more difficult.
If you need random machines to be RADIUS clients, you should use RADIUS over TLS. v3 supports it. You can put a local proxy onto the remote site, and then have that proxy connect to a central server. The central server can then do certificate authentication of the edge machines.
Anything else is insecure, and terrible in practice. It doesn't matter if it's convenient. Not using protection is convenient. But the side effects can be grim.
If you want to use rlm_raw in v3, go right ahead. But the build system has changed. The internal APIs have changed. You'll have to know C in order to get it working.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
In the scenario of the public wifi service provider (eg something like hotspotsystem, cloud4wi etc), generally the hotspot is running on embedded devices with limited resources so the TLS option and local proxy is just not feasible. Plus it really impacts the "off the shelf" approach to providing such a service.
DD-WRT can cope with IPSec fine, and it runs on extremely resource constrained systems. The volume of RADIUS traffic for individual access points is also very low, so I really don't buy your argument.
Would just be nice if the option was there for those who want to use it or some alternative that can provide similar functionality then we can.
It's a terrible approach that shouldn't be encouraged. That's why the module hasn't been merged. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Jul 6, 2015, at 9:36 AM, Paul Trappitt <paul@freedomwifi.com.au> wrote:
Thanks for the response and I fully appreciate your position on it, but personally think it's useful functionality that should be available if someone wants to use it.
I disagree. Seeing as I have a strong say in what the server does, my opinion is the decisive one. It's not "useful" functionality. It's insecure, broken, and wrong.
My only current option to truly allow dynamic clients is to run the dynamic clients with 0.0.0.0/0 which deems it completely insecure anyway.
That is the standard way. And to be honest, more secure than your suggested method.
If IP addresses of nas are constantly changing then the IP isn't a value that can be used to securely identify the device anyway so it becomes a bit null and void.
Which is why RADIUS over TLS was standardized.
We're then left processing the rest of the packet to find the same data we can get from raw and just rejecting the request later down the track.
No.
In the scenario of the public wifi service provider (eg something like hotspotsystem, cloud4wi etc), generally the hotspot is running on embedded devices with limited resources so the TLS option and local proxy is just not feasible.
Nonsense. They can run radsecproxy, or FreeRADIUS with minimal impact. If the embedded system can run a web server and 10 WiFi clients, it can run a RADIUS proxy with TLS.
Plus it really impacts the "off the shelf" approach to providing such a service.
It's your choice to use a non-standard and insecure solution.
Would just be nice if the option was there for those who want to use it or some alternative that can provide similar functionality then we can.
You can port rlm_raw to v3, and maintain it yourself. Alan DeKok.
For what it’s worth we currently have several thousand APs deployed across multiple sites/states as part of a managed WiFi solution for K-12 school systems and are doing exactly what Alan has suggested. The APs connect via RADSEC and we have a single 0.0.0.0/0 client entry which enforces TLS. We us this in conjunction with the rlm_couchbase module to collect real-time accounting and provide captive portal authentication/guest registration. We’ve been doing this since before 3.0.x was even officially released and it’s been working better than anticipated and scales wonderfully. — Aaron
On Jul 7, 2015, at 3:16 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 6, 2015, at 9:36 AM, Paul Trappitt <paul@freedomwifi.com.au> wrote:
Thanks for the response and I fully appreciate your position on it, but personally think it's useful functionality that should be available if someone wants to use it.
I disagree. Seeing as I have a strong say in what the server does, my opinion is the decisive one.
It's not "useful" functionality. It's insecure, broken, and wrong.
My only current option to truly allow dynamic clients is to run the dynamic clients with 0.0.0.0/0 which deems it completely insecure anyway.
That is the standard way. And to be honest, more secure than your suggested method.
If IP addresses of nas are constantly changing then the IP isn't a value that can be used to securely identify the device anyway so it becomes a bit null and void.
Which is why RADIUS over TLS was standardized.
We're then left processing the rest of the packet to find the same data we can get from raw and just rejecting the request later down the track.
No.
In the scenario of the public wifi service provider (eg something like hotspotsystem, cloud4wi etc), generally the hotspot is running on embedded devices with limited resources so the TLS option and local proxy is just not feasible.
Nonsense. They can run radsecproxy, or FreeRADIUS with minimal impact. If the embedded system can run a web server and 10 WiFi clients, it can run a RADIUS proxy with TLS.
Plus it really impacts the "off the shelf" approach to providing such a service.
It's your choice to use a non-standard and insecure solution.
Would just be nice if the option was there for those who want to use it or some alternative that can provide similar functionality then we can.
You can port rlm_raw to v3, and maintain it yourself.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Hi Aaron, Thanks for the info, are you able to provide any links or details on how to set this up please? I can't find any documentation on setting up dynamic clients with TLS enabled. Cheers On Wed, Jul 8, 2015 at 8:25 AM, Aaron Hurt via Freeradius-Devel < freeradius-devel@lists.freeradius.org> wrote:
For what it’s worth we currently have several thousand APs deployed across multiple sites/states as part of a managed WiFi solution for K-12 school systems and are doing exactly what Alan has suggested. The APs connect via RADSEC and we have a single 0.0.0.0/0 client entry which enforces TLS. We us this in conjunction with the rlm_couchbase module to collect real-time accounting and provide captive portal authentication/guest registration. We’ve been doing this since before 3.0.x was even officially released and it’s been working better than anticipated and scales wonderfully.
— Aaron
On Jul 7, 2015, at 3:16 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 6, 2015, at 9:36 AM, Paul Trappitt <paul@freedomwifi.com.au> wrote:
Thanks for the response and I fully appreciate your position on it, but personally think it's useful functionality that should be available if someone wants to use it.
I disagree. Seeing as I have a strong say in what the server does, my opinion is the decisive one.
It's not "useful" functionality. It's insecure, broken, and wrong.
My only current option to truly allow dynamic clients is to run the dynamic clients with 0.0.0.0/0 which deems it completely insecure anyway.
That is the standard way. And to be honest, more secure than your suggested method.
If IP addresses of nas are constantly changing then the IP isn't a value that can be used to securely identify the device anyway so it becomes a bit null and void.
Which is why RADIUS over TLS was standardized.
We're then left processing the rest of the packet to find the same data we can get from raw and just rejecting the request later down the track.
No.
In the scenario of the public wifi service provider (eg something like hotspotsystem, cloud4wi etc), generally the hotspot is running on embedded devices with limited resources so the TLS option and local proxy is just not feasible.
Nonsense. They can run radsecproxy, or FreeRADIUS with minimal impact. If the embedded system can run a web server and 10 WiFi clients, it can run a RADIUS proxy with TLS.
Plus it really impacts the "off the shelf" approach to providing such a service.
It's your choice to use a non-standard and insecure solution.
Would just be nice if the option was there for those who want to use it or some alternative that can provide similar functionality then we can.
You can port rlm_raw to v3, and maintain it yourself.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Sorry for the late response. There is a pretty good example included with the FR source ( https://github.com/FreeRADIUS/freeradius-server/blob/v3.1.x/raddb/sites-avai... <https://github.com/FreeRADIUS/freeradius-server/blob/v3.1.x/raddb/sites-available/tls> ). That site example describes the server and client sections to enforce RADIUS over TCP/TLS (RadSec). — Aaron
On Jul 14, 2015, at 2:36 AM, Paul Trappitt <paul@freedomwifi.com.au> wrote:
Hi Aaron,
Thanks for the info, are you able to provide any links or details on how to set this up please? I can't find any documentation on setting up dynamic clients with TLS enabled.
Cheers
On Wed, Jul 8, 2015 at 8:25 AM, Aaron Hurt via Freeradius-Devel <freeradius-devel@lists.freeradius.org <mailto:freeradius-devel@lists.freeradius.org>> wrote: For what it’s worth we currently have several thousand APs deployed across multiple sites/states as part of a managed WiFi solution for K-12 school systems and are doing exactly what Alan has suggested. The APs connect via RADSEC and we have a single 0.0.0.0/0 <http://0.0.0.0/0> client entry which enforces TLS. We us this in conjunction with the rlm_couchbase module to collect real-time accounting and provide captive portal authentication/guest registration. We’ve been doing this since before 3.0.x was even officially released and it’s been working better than anticipated and scales wonderfully.
— Aaron
On Jul 7, 2015, at 3:16 PM, Alan DeKok <aland@deployingradius.com <mailto:aland@deployingradius.com>> wrote:
On Jul 6, 2015, at 9:36 AM, Paul Trappitt <paul@freedomwifi.com.au <mailto:paul@freedomwifi.com.au>> wrote:
Thanks for the response and I fully appreciate your position on it, but personally think it's useful functionality that should be available if someone wants to use it.
I disagree. Seeing as I have a strong say in what the server does, my opinion is the decisive one.
It's not "useful" functionality. It's insecure, broken, and wrong.
My only current option to truly allow dynamic clients is to run the dynamic clients with 0.0.0.0/0 <http://0.0.0.0/0> which deems it completely insecure anyway.
That is the standard way. And to be honest, more secure than your suggested method.
If IP addresses of nas are constantly changing then the IP isn't a value that can be used to securely identify the device anyway so it becomes a bit null and void.
Which is why RADIUS over TLS was standardized.
We're then left processing the rest of the packet to find the same data we can get from raw and just rejecting the request later down the track.
No.
In the scenario of the public wifi service provider (eg something like hotspotsystem, cloud4wi etc), generally the hotspot is running on embedded devices with limited resources so the TLS option and local proxy is just not feasible.
Nonsense. They can run radsecproxy, or FreeRADIUS with minimal impact. If the embedded system can run a web server and 10 WiFi clients, it can run a RADIUS proxy with TLS.
Plus it really impacts the "off the shelf" approach to providing such a service.
It's your choice to use a non-standard and insecure solution.
Would just be nice if the option was there for those who want to use it or some alternative that can provide similar functionality then we can.
You can port rlm_raw to v3, and maintain it yourself.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html <http://www.freeradius.org/list/devel.html>
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html <http://www.freeradius.org/list/devel.html>
Hi Aaron, No worries thanks for taking the time to get back to me and for the info. I've managed to get the TLS side of things working, but how do I chain this to the dynamic clients side of things? I can see in the tls example it references a clients section of radsec. I've tried modifying this to 0.0.0.0/0 and defining a dynamic_clients setting, but that doesn't feel like it's going in the right direction plus it doesn't work. I just get Ignoring request to auth+acct proto tcp address * port 2083 (TLS) bound to server default from unknown client 172.17.0.73 port 42065 proto tcp Which seems to me as though it's not actually hitting the dynamic clients server. Any assistance would be greatly appreciated Kind Regards Paul On Tue, Jul 14, 2015 at 8:57 PM, Aaron Hurt <ahurt@ena.com> wrote:
Sorry for the late response. There is a pretty good example included with the FR source ( https://github.com/FreeRADIUS/freeradius-server/blob/v3.1.x/raddb/sites-avai... ). That site example describes the server and client sections to enforce RADIUS over TCP/TLS (RadSec).
— Aaron
On Jul 14, 2015, at 2:36 AM, Paul Trappitt <paul@freedomwifi.com.au> wrote:
Hi Aaron,
Thanks for the info, are you able to provide any links or details on how to set this up please? I can't find any documentation on setting up dynamic clients with TLS enabled.
Cheers
On Wed, Jul 8, 2015 at 8:25 AM, Aaron Hurt via Freeradius-Devel < freeradius-devel@lists.freeradius.org> wrote:
For what it’s worth we currently have several thousand APs deployed across multiple sites/states as part of a managed WiFi solution for K-12 school systems and are doing exactly what Alan has suggested. The APs connect via RADSEC and we have a single 0.0.0.0/0 client entry which enforces TLS. We us this in conjunction with the rlm_couchbase module to collect real-time accounting and provide captive portal authentication/guest registration. We’ve been doing this since before 3.0.x was even officially released and it’s been working better than anticipated and scales wonderfully.
— Aaron
On Jul 7, 2015, at 3:16 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 6, 2015, at 9:36 AM, Paul Trappitt <paul@freedomwifi.com.au> wrote:
Thanks for the response and I fully appreciate your position on it, but personally think it's useful functionality that should be available if someone wants to use it.
I disagree. Seeing as I have a strong say in what the server does, my opinion is the decisive one.
It's not "useful" functionality. It's insecure, broken, and wrong.
My only current option to truly allow dynamic clients is to run the dynamic clients with 0.0.0.0/0 which deems it completely insecure anyway.
That is the standard way. And to be honest, more secure than your suggested method.
If IP addresses of nas are constantly changing then the IP isn't a value that can be used to securely identify the device anyway so it becomes a bit null and void.
Which is why RADIUS over TLS was standardized.
We're then left processing the rest of the packet to find the same data we can get from raw and just rejecting the request later down the track.
No.
In the scenario of the public wifi service provider (eg something like hotspotsystem, cloud4wi etc), generally the hotspot is running on embedded devices with limited resources so the TLS option and local proxy is just not feasible.
Nonsense. They can run radsecproxy, or FreeRADIUS with minimal impact. If the embedded system can run a web server and 10 WiFi clients, it can run a RADIUS proxy with TLS.
Plus it really impacts the "off the shelf" approach to providing such a service.
It's your choice to use a non-standard and insecure solution.
Would just be nice if the option was there for those who want to use it or some alternative that can provide similar functionality then we can.
You can port rlm_raw to v3, and maintain it yourself.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Hi Aaron, It's ok I managed to work it out. just set the clients radesc section to 0.0.0.0/0, just helps if you are modifying the correct tls config file! haha Thanks again for the help. Now to just get some sort of centralised CA infrastructure in place so we can run multiple radius servers Kind Regards Paul On Fri, Jul 17, 2015 at 10:15 AM, Paul Trappitt <paul@freedomwifi.com.au> wrote:
Hi Aaron,
No worries thanks for taking the time to get back to me and for the info. I've managed to get the TLS side of things working, but how do I chain this to the dynamic clients side of things? I can see in the tls example it references a clients section of radsec. I've tried modifying this to 0.0.0.0/0 and defining a dynamic_clients setting, but that doesn't feel like it's going in the right direction plus it doesn't work.
I just get Ignoring request to auth+acct proto tcp address * port 2083 (TLS) bound to server default from unknown client 172.17.0.73 port 42065 proto tcp
Which seems to me as though it's not actually hitting the dynamic clients server.
Any assistance would be greatly appreciated
Kind Regards Paul
On Tue, Jul 14, 2015 at 8:57 PM, Aaron Hurt <ahurt@ena.com> wrote:
Sorry for the late response. There is a pretty good example included with the FR source ( https://github.com/FreeRADIUS/freeradius-server/blob/v3.1.x/raddb/sites-avai... ). That site example describes the server and client sections to enforce RADIUS over TCP/TLS (RadSec).
— Aaron
On Jul 14, 2015, at 2:36 AM, Paul Trappitt <paul@freedomwifi.com.au> wrote:
Hi Aaron,
Thanks for the info, are you able to provide any links or details on how to set this up please? I can't find any documentation on setting up dynamic clients with TLS enabled.
Cheers
On Wed, Jul 8, 2015 at 8:25 AM, Aaron Hurt via Freeradius-Devel < freeradius-devel@lists.freeradius.org> wrote:
For what it’s worth we currently have several thousand APs deployed across multiple sites/states as part of a managed WiFi solution for K-12 school systems and are doing exactly what Alan has suggested. The APs connect via RADSEC and we have a single 0.0.0.0/0 client entry which enforces TLS. We us this in conjunction with the rlm_couchbase module to collect real-time accounting and provide captive portal authentication/guest registration. We’ve been doing this since before 3.0.x was even officially released and it’s been working better than anticipated and scales wonderfully.
— Aaron
On Jul 7, 2015, at 3:16 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 6, 2015, at 9:36 AM, Paul Trappitt <paul@freedomwifi.com.au> wrote:
Thanks for the response and I fully appreciate your position on it, but personally think it's useful functionality that should be available if someone wants to use it.
I disagree. Seeing as I have a strong say in what the server does, my opinion is the decisive one.
It's not "useful" functionality. It's insecure, broken, and wrong.
My only current option to truly allow dynamic clients is to run the dynamic clients with 0.0.0.0/0 which deems it completely insecure anyway.
That is the standard way. And to be honest, more secure than your suggested method.
If IP addresses of nas are constantly changing then the IP isn't a value that can be used to securely identify the device anyway so it becomes a bit null and void.
Which is why RADIUS over TLS was standardized.
We're then left processing the rest of the packet to find the same data we can get from raw and just rejecting the request later down the track.
No.
In the scenario of the public wifi service provider (eg something like hotspotsystem, cloud4wi etc), generally the hotspot is running on embedded devices with limited resources so the TLS option and local proxy is just not feasible.
Nonsense. They can run radsecproxy, or FreeRADIUS with minimal impact. If the embedded system can run a web server and 10 WiFi clients, it can run a RADIUS proxy with TLS.
Plus it really impacts the "off the shelf" approach to providing such a service.
It's your choice to use a non-standard and insecure solution.
Would just be nice if the option was there for those who want to use it or some alternative that can provide similar functionality then we can.
You can port rlm_raw to v3, and maintain it yourself.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Yes, that’s it. Glad you got it working … it really does make things much easier to manage and more secure once you get things setup. — Aaron
On Jul 16, 2015, at 10:09 PM, Paul Trappitt <paul@freedomwifi.com.au> wrote:
Hi Aaron,
It's ok I managed to work it out. just set the clients radesc section to 0.0.0.0/0 <http://0.0.0.0/0>, just helps if you are modifying the correct tls config file! haha
Thanks again for the help. Now to just get some sort of centralised CA infrastructure in place so we can run multiple radius servers
Kind Regards Paul
On Fri, Jul 17, 2015 at 10:15 AM, Paul Trappitt <paul@freedomwifi.com.au <mailto:paul@freedomwifi.com.au>> wrote: Hi Aaron,
No worries thanks for taking the time to get back to me and for the info. I've managed to get the TLS side of things working, but how do I chain this to the dynamic clients side of things? I can see in the tls example it references a clients section of radsec. I've tried modifying this to 0.0.0.0/0 <http://0.0.0.0/0> and defining a dynamic_clients setting, but that doesn't feel like it's going in the right direction plus it doesn't work.
I just get Ignoring request to auth+acct proto tcp address * port 2083 (TLS) bound to server default from unknown client 172.17.0.73 port 42065 proto tcp
Which seems to me as though it's not actually hitting the dynamic clients server.
Any assistance would be greatly appreciated
Kind Regards Paul
On Tue, Jul 14, 2015 at 8:57 PM, Aaron Hurt <ahurt@ena.com <mailto:ahurt@ena.com>> wrote: Sorry for the late response. There is a pretty good example included with the FR source ( https://github.com/FreeRADIUS/freeradius-server/blob/v3.1.x/raddb/sites-avai... <https://github.com/FreeRADIUS/freeradius-server/blob/v3.1.x/raddb/sites-available/tls> ). That site example describes the server and client sections to enforce RADIUS over TCP/TLS (RadSec).
— Aaron
On Jul 14, 2015, at 2:36 AM, Paul Trappitt <paul@freedomwifi.com.au <mailto:paul@freedomwifi.com.au>> wrote:
Hi Aaron,
Thanks for the info, are you able to provide any links or details on how to set this up please? I can't find any documentation on setting up dynamic clients with TLS enabled.
Cheers
On Wed, Jul 8, 2015 at 8:25 AM, Aaron Hurt via Freeradius-Devel <freeradius-devel@lists.freeradius.org <mailto:freeradius-devel@lists.freeradius.org>> wrote: For what it’s worth we currently have several thousand APs deployed across multiple sites/states as part of a managed WiFi solution for K-12 school systems and are doing exactly what Alan has suggested. The APs connect via RADSEC and we have a single 0.0.0.0/0 <http://0.0.0.0/0> client entry which enforces TLS. We us this in conjunction with the rlm_couchbase module to collect real-time accounting and provide captive portal authentication/guest registration. We’ve been doing this since before 3.0.x was even officially released and it’s been working better than anticipated and scales wonderfully.
— Aaron
On Jul 7, 2015, at 3:16 PM, Alan DeKok <aland@deployingradius.com <mailto:aland@deployingradius.com>> wrote:
On Jul 6, 2015, at 9:36 AM, Paul Trappitt <paul@freedomwifi.com.au <mailto:paul@freedomwifi.com.au>> wrote:
Thanks for the response and I fully appreciate your position on it, but personally think it's useful functionality that should be available if someone wants to use it.
I disagree. Seeing as I have a strong say in what the server does, my opinion is the decisive one.
It's not "useful" functionality. It's insecure, broken, and wrong.
My only current option to truly allow dynamic clients is to run the dynamic clients with 0.0.0.0/0 <http://0.0.0.0/0> which deems it completely insecure anyway.
That is the standard way. And to be honest, more secure than your suggested method.
If IP addresses of nas are constantly changing then the IP isn't a value that can be used to securely identify the device anyway so it becomes a bit null and void.
Which is why RADIUS over TLS was standardized.
We're then left processing the rest of the packet to find the same data we can get from raw and just rejecting the request later down the track.
No.
In the scenario of the public wifi service provider (eg something like hotspotsystem, cloud4wi etc), generally the hotspot is running on embedded devices with limited resources so the TLS option and local proxy is just not feasible.
Nonsense. They can run radsecproxy, or FreeRADIUS with minimal impact. If the embedded system can run a web server and 10 WiFi clients, it can run a RADIUS proxy with TLS.
Plus it really impacts the "off the shelf" approach to providing such a service.
It's your choice to use a non-standard and insecure solution.
Would just be nice if the option was there for those who want to use it or some alternative that can provide similar functionality then we can.
You can port rlm_raw to v3, and maintain it yourself.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html <http://www.freeradius.org/list/devel.html>
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html <http://www.freeradius.org/list/devel.html>
participants (7)
-
Aaron Hurt -
Alan DeKok -
Arran Cudbard-Bell -
Jorge Pereira -
Matthew Newton -
Paul Trappitt -
Stefan Paetow