rlm_raw in 3.1.x

[Paul Trappitt]

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 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 ).
> 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>
> 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> 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 at deployingradius.com>
>> wrote:
>> >
>> > On Jul 6, 2015, at 9:36 AM, Paul Trappitt <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 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
>>
>
>
>