rlm_raw in 3.1.x

Fri Jul 17 17:21:27 CEST 2015

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 at 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 at freedomwifi.com.au <mailto:paul at 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 at ena.com <mailto:ahurt at 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-available/tls <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 at freedomwifi.com.au <mailto:paul at 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 at lists.freeradius.org <mailto:freeradius-devel at 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 at deployingradius.com <mailto:aland at deployingradius.com>> wrote:
>> >
>> > On Jul 6, 2015, at 9:36 AM, Paul Trappitt <paul at freedomwifi.com.au <mailto:paul at 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>
>> 
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20150717/391546ce/attachment.sig>