Hello, 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. 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. 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. I was of the opinion that secret is different, so lookup can be solved. But from the *dynamic_clients* documentation, it reads as, "*You can specify overlapping networks (127/8 and 127.0/16)*.* In that case, the smallest possible network will be used as the "best match" for the client.*" But in mycase it is overlapping IPs. I also read that some NAS clients do allow to change NAS-IP address, and some don't. At first, I thought relying on the NAS-IP address instead of Packet-Src-Ip-Address as Packet-Src-Ip-Address is same in radius auth packets from both sources. But apparently, I see the NAS IP address remains the same, and some NAS clients don't allow to change their NAS IP address. *Questions are:* *1. Is this the correct configuration (where two NAS clients under same roof)? If yes, is it a solved use case? * *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 ? * *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.* This is the current query (default from the package, as I haven't changed anything) if ("%{sql: SELECT nasname FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}") { update control { # # Echo the IP. &FreeRADIUS-Client-IP-Address = "%{Packet-Src-IP-Address}" # # Do multiple SELECT statements to grab # the various definitions. &FreeRADIUS-Client-Shortname = "%{sql: SELECT shortname FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}" &FreeRADIUS-Client-Secret = "%{sql: SELECT secret FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}" &FreeRADIUS-Client-NAS-Type = "%{sql: SELECT type FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}" &FreeRADIUS-Client-Virtual-Server = "%{sql: SELECT server FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}" } } Thanks, Sachin
do the debug logs confirm your conclusion ? Jonathan Davis On 2022-10-04 10:34 a.m., sachin shetty wrote:
Hello,
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.
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.
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.
I was of the opinion that secret is different, so lookup can be solved. But from the *dynamic_clients* documentation, it reads as, "*You can specify overlapping networks (127/8 and 127.0/16)*.* In that case, the smallest possible network will be used as the "best match" for the client.*" But in mycase it is overlapping IPs. I also read that some NAS clients do allow to change NAS-IP address, and some don't. At first, I thought relying on the NAS-IP address instead of Packet-Src-Ip-Address as Packet-Src-Ip-Address is same in radius auth packets from both sources. But apparently, I see the NAS IP address remains the same, and some NAS clients don't allow to change their NAS IP address.
*Questions are:*
*1. Is this the correct configuration (where two NAS clients under same roof)? If yes, is it a solved use case? *
*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 ? *
*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.*
This is the current query (default from the package, as I haven't changed anything)
if ("%{sql: SELECT nasname FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}") { update control { # # Echo the IP. &FreeRADIUS-Client-IP-Address = "%{Packet-Src-IP-Address}"
# # Do multiple SELECT statements to grab # the various definitions. &FreeRADIUS-Client-Shortname = "%{sql: SELECT shortname FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}"
&FreeRADIUS-Client-Secret = "%{sql: SELECT secret FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}"
&FreeRADIUS-Client-NAS-Type = "%{sql: SELECT type FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}"
&FreeRADIUS-Client-Virtual-Server = "%{sql: SELECT server FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}" }
}
Thanks, Sachin - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Yes, I confirmed this behavior post debug. On Tue, Oct 4, 2022 at 8:21 PM Jonathan Davis <jonathan@prioritycolo.com> wrote:
do the debug logs confirm your conclusion ?
Jonathan Davis
Hello,
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.
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.
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.
I was of the opinion that secret is different, so lookup can be solved. But from the *dynamic_clients* documentation, it reads as, "*You can specify overlapping networks (127/8 and 127.0/16)*.* In that case, the smallest possible network will be used as the "best match" for the client.*" But in mycase it is overlapping IPs. I also read that some NAS clients do allow to change NAS-IP address, and some don't. At first, I thought relying on the NAS-IP address instead of Packet-Src-Ip-Address as Packet-Src-Ip-Address is same in radius auth packets from both sources. But apparently, I see the NAS IP address remains the same, and some NAS clients don't allow to change their NAS IP address.
*Questions are:*
*1. Is this the correct configuration (where two NAS clients under same roof)? If yes, is it a solved use case? *
*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 ? *
*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.*
This is the current query (default from the package, as I haven't changed anything)
if ("%{sql: SELECT nasname FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}") { update control { # # Echo the IP. &FreeRADIUS-Client-IP-Address = "%{Packet-Src-IP-Address}"
# # Do multiple SELECT statements to grab # the various definitions. &FreeRADIUS-Client-Shortname = "%{sql: SELECT shortname FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}"
&FreeRADIUS-Client-Secret = "%{sql: SELECT secret FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}"
&FreeRADIUS-Client-NAS-Type = "%{sql: SELECT type FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}"
&FreeRADIUS-Client-Virtual-Server = "%{sql: SELECT server FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}" }
}
Thanks, Sachin - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 2022-10-04 10:34 a.m., sachin shetty wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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.
Alan DeKok <aland@deployingradius.com> wrote:
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.
That surely cannot be emphasized enough. It's surprising people do it. Let's assume the remote site traffic is safely tunneled by other means, though. If the user cannot set up a RadSec proxy server at the branch, then what I would recommend is to run a remote proxy instance of FreeRADIUS in addition to the main FreeRADIUS server. Send one of the two clients there instead of to the main RADIUS server. That proxy server instance would have a separate database of clients with the keys for that particular client appliance, and then would use the home server secret when relaying to the main FreeRADIUS instance. The two instances could be on the same machine, just using different ports. You just have to keep the config files separate for each process. But... as Alan said... I do not recommend this unless you have a means to keep the RADIUS/UDP traffic in an encrypted tunnel between the branch and home office. And if you have an encrypted tunnel, you can probably run routes through it and give the VPN and WiFi different, private, IP addresses, even if they are the same appliance. - List info/subscribe/unsubscribe? See https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeradius.org%2Flist%2Fusers.html&data=05%7C01%7Cbjulin%40clarku.edu%7Ce744cbbe4faf4df28c2f08daa6219ff9%7Cb5b2263d68aa453eb972aa1421410f80%7C0%7C0%7C638004960609891991%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OHFCE55ub82mzQjaxJ9XLvwxaRc7g%2BxHtxNicCqIiW4%3D&reserved=0
On Oct 4, 2022, at 1:39 PM, Brian Julin <BJulin@clarku.edu> wrote:
Alan DeKok <aland@deployingradius.com> wrote:
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.
That surely cannot be emphasized enough. It's surprising people do it.
I just submitted a document to the IETF: https://datatracker.ietf.org/doc/html/draft-dekok-radext-deprecating-radius-... And wrote an article on it: https://networkradius.com/articles/2022/10/04/radius-insecurity.html From the IETF document: 4. All short Shared Secrets have been compromised Unless RADIUS packets are sent over a secure network (IPSec, TLS, etc.), administrators should assume that any shared secret of 8 characters or less has been immediately compromised. Administrators should assume that any shared secret of 10 characters or less has been compromised by an attacker with significant resources. Administrators should also assume that any private information (such as User-Password) which depends on such shared secrets has also been compromised. Further, if a User-Password has been sent over the Internet via RADIUS/UDP or RADIUS/TCP in the last decade, you should assume that password has been compromised by an attacker with sufficient resources.
How about RADIUS over QUIC I’m guessing RADIUS would lend itself more to the UDP transport. If I had the time I’d steal the DNS over QUIC work and err create the same thing for RADIUS. A. From: Freeradius-Users <freeradius-users-bounces+alister.winfield=sky.uk@lists.freeradius.org> on behalf of Alan DeKok <aland@deployingradius.com> Date: Tuesday, 4 October 2022 at 19:24 To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: [EXTERNAL] Re: [EXT] Multiple NAS clients within same network On Oct 4, 2022, at 1:39 PM, Brian Julin <BJulin@clarku.edu> wrote:
Alan DeKok <aland@deployingradius.com> wrote:
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.
That surely cannot be emphasized enough. It's surprising people do it.
I just submitted a document to the IETF: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dekok-radext-deprecating-radius-00&data=05%7C01%7Calister.winfield%40sky.uk%7Ca85abcd1e2f74d92f7d808daa6358d11%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C638005046766666836%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FedMlXrDPP4l79kYzfwonR6OgR4NFdag885zjWVlWfE%3D&reserved=0 And wrote an article on it: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnetworkradius.com%2Farticles%2F2022%2F10%2F04%2Fradius-insecurity.html&data=05%7C01%7Calister.winfield%40sky.uk%7Ca85abcd1e2f74d92f7d808daa6358d11%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C638005046766666836%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gWbY5TAR3d4mo9dfPrC2fB2JVDksHCt1tKHYiaPjzGo%3D&reserved=0 From the IETF document: 4. All short Shared Secrets have been compromised Unless RADIUS packets are sent over a secure network (IPSec, TLS, etc.), administrators should assume that any shared secret of 8 characters or less has been immediately compromised. Administrators should assume that any shared secret of 10 characters or less has been compromised by an attacker with significant resources. Administrators should also assume that any private information (such as User-Password) which depends on such shared secrets has also been compromised. Further, if a User-Password has been sent over the Internet via RADIUS/UDP or RADIUS/TCP in the last decade, you should assume that password has been compromised by an attacker with sufficient resources. - List info/subscribe/unsubscribe? See https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeradius.org%2Flist%2Fusers.html&data=05%7C01%7Calister.winfield%40sky.uk%7Ca85abcd1e2f74d92f7d808daa6358d11%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C638005046766666836%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HBfuZvlq25r8QvJd4%2BuBRxAplnaJfOVOnAw%2FrjZ798M%3D&reserved=0 -------------------------------------------------------------------- This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by using the report message button in Outlook or sending them as an attachment to phishing@sky.uk. Thank you -------------------------------------------------------------------- Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD
On Oct 4, 2022, at 4:04 PM, Winfield, Alister (Senior Solutions Architect) via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
How about RADIUS over QUIC I’m guessing RADIUS would lend itself more to the UDP transport. If I had the time I’d steal the DNS over QUIC work and err create the same thing for RADIUS.
I'm happy to accept patches. :) The IETF is also free to participate in. So it's possible to write a spec proposing it. That being said, the RADIUS over TLS documents have been out for a decade. Many NASes still don't implement it. It's time to make a lot of noise about this, and highlight just how bad the problem is. FreeRADIUS is *free*. It's relatively trivial to implement RadSec. FreeRADIUS comes with some simple scripts to manage certificates. It should take about an hour to add RadSec to a FreeRADIUS configuration. Alan DeKok.
On Tue, 4 Oct 2022, at 21:04, Winfield, Alister (Senior Solutions Architect) wrote:
How about RADIUS over QUIC
Maybe easier to use RADIUS over DTLS[1] which is an experimental thing and apparently implemented by Cisco; though not FreeRADIUS. At least with DTLS, you get to use the existing dependencies of your SSL library. Cheers [1] https://www.rfc-editor.org/rfc/rfc7360.html
participants (6)
-
Alan DeKok -
Alexander Clouter -
Brian Julin -
Jonathan Davis -
sachin shetty -
Winfield, Alister (Senior Solutions Architect)