Dynamic Clients

[Arran Cudbard-Bell]

On 14 Aug 2014, at 07:48, Kev Pearce <email.me at kevp.com> wrote:

> Thanks for the comments Alan.
> 
> I can lookup clients in my nas table by NAS-IP-Address just fine, I get that
> bit but I can't get FR to 'cache' the reply (and therefore process the
> request as accepted) as it always ends up referring (keying) to the source
> IP address.
> 
>> - Cannot add client 192.168.26.119: IP address 10.10.10.10 do not match

That constraint is still there in v3.0.x. Why would you want to add a 
client that doesn't match the src IP address of the packet you just
received?

If you want to add 10.10.10.10 then get it to send the packet directly.

> What I need FR to do is to see the packet as coming from the NAS-IP-Address
> field, in this example 10.10.10.10 so it does match the reply from the sql
> nas table query.
> The source IP of the radius packet here is 192.168.26.119 and I need FR to
> use 10.10.10.10 instead, in this example.
> I can't see how to set FR up to do this, to me this is more than just
> dynamic-clients setup, it more fundamental to the way FR clients works.
> I wondered if there was anything I could change in configure?

I think what you're not understanding here, is that the RADIUS packet parser
isn't called on the packet until the src IP field in the header is matched
to a client definition.

There's no way to key clients on NAS-IP-Address because that attribute simply
isn't available when the client lookup is being done.

Doing the full decode before validation increases the risk someone will be 
able to DoS the server.

People have hacked modules together like 'rlm_raw', but it's generally a bad
idea to do things that way, and will likely degrade performance.

I guess the question is why do you need to run NAT here? Does your ISP
not support IPv6 yet?

>> It's really about security.  If you need random clients connecting to your
> server, you should be using RADIUS over TLS.
> 
> RADIUS over TLS is for my next workstream, for now I'd like to get FR
> working nice and simple (for the users anyway!) with NAS-IP-Address and
> secrets per NAS.
> 
> Or is the only answer to the keying of NAS-IP-Address (which is just the
> original IP address of the packet before the source IP is NATted over the
> internet) actually TLS...
> Does FR see the original source IP address of the NAS as the source IP of
> the packet, once the TLS is unwrapped?

No.

But you can base any logic off NAS-IP-Address. The client definitions don't
matter so much with TLS as the trust relationship is established using
certificates.

>> Because you told it to look up the client as dynamic.  What else did you
> expect?
> 
> Thank you, that confirms a few things (longest netmask wins, just like IP
> routing) and I now have a plan B that I've tested and works great.
> 
> Cheers very much once again,

Just to note that adding IP ranges dynamically does work in v3.0.x.
The check is then relaxed to ensure the src IP address is in the range
which was just added.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140814/e3d25b0b/attachment-0001.pgp>