Hi all, I've spent many hours now trying to get dynamics clients working the way I would like them too. But I've now got to the point where I need to reach out to the list for help. I appreciate this is a long email with a lot of questions but I have worked hard to get this working myself... I just need some pointers now... I'm running freeradius 2.2.5 on Ubuntu 14.04 with MySQL 5.5 Thank you very much all for all your help, Kev/. Deep breath... 1) Is it possible to 'key' all clients by the NAS-IP-Address field rather than the source IP address field? I do appreciate that RFC2865 states that is MUST NOT be used, but that was back in 2000, when Cloud and SaaS hosting didn't exist. Being how flexible freeradius is, I was wondering if this would be possible or has been done before. 2) Can Dynamics Clients also be keyed by NAS-IP-Address (naturally linked to q1)? I've built my freeradius with the raw module and can do all the dynamic clients SQL queries using NAS-IP-Address fine, BUT freeradius refuses to cache the client secret with the message: rad_recv: Access-Request packet from host 192.168.26.119 port 37350, id=43, length=86 server dynamic_client_server { rlm_raw: NAS-IP-Address = 10.10.10.10 rlm_sql (sql): Reserving sql socket id: 1 rlm_sql_mysql: query: SELECT secret FROM nas WHERE nas-ip-address='10.10.10.10' rlm_sql (sql): Released sql socket id: 1 } # server dynamic_client_server - Cannot add client 192.168.26.119: IP address 10.10.10.10 do not match Ignoring request to authentication address * port 1812 from unknown client 192.168.26.119 port 37350 Ready to process requests. This happens when in my dynamic_clients update control, I have: FreeRADIUS-Client-IP-Address = "%{raw:NAS-IP-Address}" All works great if I use the source IP address but I'd like to use NAS-IP-Address. 3) Can a dynamic client set to match 0.0.0.0/0, support loading a 0.0.0.0/0 client from sql on start up? If I have a client defined in my nas table with the nasname 0.0.0.0/0, I get the following message on start up: rlm_sql_mysql: query: SELECT id, nasname, shortname, type, secret, server FROM nas rlm_sql (sql): Read entry nasname=0.0.0.0/0,shortname=All,secret=xxxxxxxx rlm_sql (sql): Adding client 0.0.0.0 (All, server=<none>) to clients list Failed to add duplicate client All rlm_sql (sql): Released sql socket id: 4 rlm_sql (sql): Failed to add client 0.0.0.0 (All) to clients list. Maybe there's a duplicate? Failed to load clients from SQL. This does of course tell me what the problem is but is there a way to have a 0.0.0.0/0 client? I've tested having 0.0.0.0/1 and 128.0.0.0/1 as two separate clients pointing to one dynamic clients virtual server, like this: client dynamic_bottom { ipaddr = 0.0.0.0 netmask = 1 dynamic_clients = dynamic_client_server lifetime = 3600 } client dynamic_top { ipaddr = 128.0.0.0 netmask = 1 dynamic_clients = dynamic_client_server lifetime = 3600 } server dynamic_client_server { authorize { if ("%{sql:SELECT nasname FROM nas ... Now this does start up fine without error and reports: rlm_sql_mysql: query: SELECT id, nasname, shortname, type, secret, server FROM nas rlm_sql (sql): Read entry nasname=0.0.0.0/0,shortname=All,secret=xxxxxxxx rlm_sql (sql): Adding client 0.0.0.0 (All, server=<none>) to clients list rlm_sql (sql): Released sql socket id: 4 But then when I try a radtest (now using normal source address matching) the client still gets looked up by the dynamic client, even though this 'All' entry should match any v4 IP address: rad_recv: Access-Request packet from host 192.168.26.119 port 44846, id=20, length=86 server dynamic_client_server { rlm_raw: NAS-IP-Address = 10.10.10.10 rlm_raw: NAS-IP-Address = 10.10.10.10 rlm_sql (sql): Reserving sql socket id: 3 rlm_sql_mysql: query: SELECT nasname FROM nas ... Is the 'read nas list on start up' stripping the /netmask and only adding 0.0.0.0 as a single hots entry? Is it possible to 'see' the list of know clients within freeradius when it is running, be them loaded at start up or learned by dynamic_clients? 4) Do dynamic clients support network address range client definition lookups in sql, i.e. nasname = 192.168.1.0/24? I've got my dynamic clients lookup sql queries working to find matching network entries when the request only has a single source IP address (using decimal ip address value comparisons and order by netmask sql queries), and the returned nasname from the sql entry to the dynamic client IS a network range but I think freeradius only caches it as a single host. It works but I think it only adds the entry as a single host, when I try from a different host in the same subnet, I see another dynamic client sql lookup. The documentation in dymanics_clients says you can do the same as you can with the normal clients file, which does support networks.
Kev Pearce wrote:
I've spent many hours now trying to get dynamics clients working the way I would like them too.
Read raddb/sites-available/dynamic-clients. This is extensively documented.
1) Is it possible to 'key' all clients by the NAS-IP-Address field rather than the source IP address field?
Not really, no. But... if you read the file I mentioned above, you can create a client based on anything you want.
I do appreciate that RFC2865 states that is MUST NOT be used, but that was back in 2000, when Cloud and SaaS hosting didn't exist.
It's really about security. If you need random clients connecting to your server, you should be using RADIUS over TLS.
2) Can Dynamics Clients also be keyed by NAS-IP-Address (naturally linked to q1)?
See above.
I've built my freeradius with the raw module and can do all the dynamic clients SQL queries using NAS-IP-Address fine, BUT freeradius refuses to cache the client secret with the message:
- Cannot add client 192.168.26.119: IP address 10.10.10.10 do not match
The packet came from 192.168.26.119, and you're telling the server to add a client with IP 10.10.10.10. That doesn't make sense.
3) Can a dynamic client set to match 0.0.0.0/0, support loading a 0.0.0.0/0 client from sql on start up?
No.
If I have a client defined in my nas table with the nasname 0.0.0.0/0, I get the following message on start up: .. Failed to add duplicate client All
Then you have two clients defined, using the same IPs. Don't do that.
I've tested having 0.0.0.0/1 and 128.0.0.0/1 as two separate clients pointing to one dynamic clients virtual server, like this:
You can just use 0.0.0.0/0.
But then when I try a radtest (now using normal source address matching) the client still gets looked up by the dynamic client, even though this 'All' entry should match any v4 IP address:
Because you told it to look up the client as dynamic. What else did you expect?
client dynamic_bottom { ipaddr = 0.0.0.0 netmask = 1 dynamic_clients = dynamic_client_server lifetime = 3600 }
That is a dynamic client. If you don't want a dynamic client, just do: client all { ipaddr = 0.0.0.0 netmask = 0 secret = testing123 } i.e. create a normal client definition.
Is it possible to 'see' the list of know clients within freeradius when it is running, be them loaded at start up or learned by dynamic_clients?
See radmin. You can query the list of known clients.
4) Do dynamic clients support network address range client definition lookups in sql, i.e. nasname = 192.168.1.0/24?
No. Dynamic clients are specific to one IP. Alan DeKok.
On 14/08/14 10:48, Alan DeKok wrote:
I do appreciate that RFC2865 states that is MUST NOT be used, but that was back in 2000, when Cloud and SaaS hosting didn't exist.
It's really about security. If you need random clients connecting to your server, you should be using RADIUS over TLS.
Just to expand on this - NAS-IP-Address is of course a payload attribute. Reading it requires parsing the packet. Parsing data from an untrusted source is best avoided. If FreeRADIUS could do this, the packet parsing would have to be two-pass - decode without authenticator (because you lack the secret), extract NAS-IP-Address, find client/secret, then validate authenticator / Message-Authenticator, and decide to drop or pass and decrypt encrypted fields.
If FreeRADIUS could do this, the packet parsing would have to be two-pass - decode without authenticator (because you lack the secret), extract NAS-IP-Address, find client/secret, then validate authenticator / Message-Authenticator, and decide to drop or pass and decrypt encrypted fields.
But doesn't the rlm_raw module provide exactly this? The ability to get to payload attributes then use them to lookup the secret etc in the dynamic-client SQL request? For the user check nas-ip-address is natively available so the user lookup by nas-ip-address is easy. I also appreciate that the raw module is not official FR code. Cheers Kev/.
On 14/08/14 13:04, Kev Pearce wrote:
If FreeRADIUS could do this, the packet parsing would have to be two-pass - decode without authenticator (because you lack the secret), extract NAS-IP-Address, find client/secret, then validate authenticator / Message-Authenticator, and decide to drop or pass and decrypt encrypted fields.
But doesn't the rlm_raw module provide exactly this? The ability to get to payload attributes then use them to lookup the secret etc in the dynamic-client SQL request?
It's obviously possible, but currently that is not how FreeRADIUS works, so no, you can't currently key off NAS-IP-Address.
For the user check nas-ip-address is natively available so the user lookup by nas-ip-address is easy.
Of course - auth processing happens after the packet is authenticated using the secret and decoded, so all attributes received are available.
I also appreciate that the raw module is not official FR code.
There are presumably reasons for this.
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
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?
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?
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, Kev/.
Kev Pearce wrote:
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.
As I said, that's wrong. You CANNOT do that. RADIUS *does not* work that way. If you want that functionality, patch the server yourself. It does not exist in the default configuration, and will NEVER work that way.
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.
No. Alan DeKok.
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
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?
Because the NASes will be NATted over the internet, the real IP might be a private RFC1918 address, but the source IP address will be a public IP. Multiple NASes would be seen as the same public IP address but have their own NAS-IP-Address values. Ok message understood. I'll stick with one secret for all clients (per virutal server at least), then use the radcheck query to check per nas based on NAS-IP-Address, which is available and safe as the packet will have passed the 'known secret' stage. I can live with this. And then I don't need the rlm_raw module, so a less hacky build. Cheers for all your input, Kev/.
On 14 Aug 2014, at 08:54, Kev Pearce <email.me@kevp.com> wrote:
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?
Because the NASes will be NATted over the internet, the real IP might be a private RFC1918 address, but the source IP address will be a public IP. Multiple NASes would be seen as the same public IP address but have their own NAS-IP-Address values.
In the brave new world of SaaS and the clouded solutions people should probably be badgering the ISPs that provide backhaul for their hotspots to be providing an IPv6 service. IPv4 NAT in this context is generally a hack, and I think not enabling those who use it is probably a positive thing for the IT community as a whole :). Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
Kev Pearce -
Phil Mayers