On Oct 4, 2022, at 10:34 AM, sachin shetty <sachinshetty.r1@gmail.com> wrote:
I'm using Freeradius for VPN and Wifi clients. Lately, I encountered a scenario wrt the NAS client IP address. Before I explain my problem to you, I'd like to give you a brief on the configuration. I'm using the dynamic_clients section, which verifies the NAS entries against the external SQL server. Post which uses rest auth for completion.
OK. That should be fine.
We have a scenario where a Wireless access point Wifi and VPN gateway are configured at the customer site, and the network has one public IP for both NAS clients.
RADIUS over UDP can't support that. There's one share secret per source IP address. That's it. If you want multiple clients behind one IP, use RADIUS/TLS. You then can verify clients by their TLS identity (certificate, etc.). And then you don't care about the IP addresses. If the clients can't do TLS, then set up a local RADIUS proxy which can do TLS.
In *the nas* table, I have two entries with the same nas name, i.e., the same client IP address but different secrets. When the Radius packet from *NAS client **1* received, it resolves to the right entry in the database and happy flow. And when the Radius packet from *NAS client 2* received it complains secret is invalid as it always picks one entry from the database. This is evident from the query pasted below for reference.
That doesn't work, and will never work.
I was of the opinion that secret is different, so lookup can be solved.
Nothing in the documentation says that this works.
*1. Is this the correct configuration (where two NAS clients under same roof)? If yes, is it a solved use case? *
It's wrong, and will never work. Use RADIUS over TLS.
*2. Should I use shortname in the query where clause? Will that help? This requires configuring shortname at the NAS client? *Or *does this mean I can have only one IP per NAS client ? *
Each RADIUS client has one IP.
*3. Any alternative approach I can look for dynamic_clients query? I do not want to skip dynamic_client auth as it efficiently blocks invalid clients. **Any reason for dynamic clients not looping all the entries matching the same IP address to compare secrets? i.e forming uniqueness with IP and secret together.*
Looping over the secret won't help. You'd have to do it for each packet which is received. You have the code, so perhaps you could "fix" the server to do this. But this patch will never be accepted into the main release. Use RADIUS over TLS. It solves this problem, and is secure. I have a document which I will be working through the IETF as a new RADIUS standard. It will officially deprecate RADIUS/UDP, and require TLS transport for most situations. The document will also explain just how bad an idea it is to run RADIUS/UDP over the Internet. Do you like people breaking all of your security? No? Then don't run RADIUS/UDP over the Internet. Alan DeKok.