On 14 Aug 2014, at 07:48, Kev Pearce <email.me@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@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2