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