I have seen several requests in this mailing list regarding the use of the NAS-Identifier for the past 8 or so years. But somehow, there seems to be still no solution on the horizon. The addition of the dynamic client feature provided great relief compared to the static client/nas list which is only loaded during the radiusd startup or SIGHUP. Anyhow, I still have the problem that clients using ISPs with shared IP addresses (e.g. some satellite providers etc) have to use exactly the same shared secret for all routers (nas) despite they might be different customers. In addition, we have clients with the nas installed on vessels and they roam between different satellite links and IP addresses. At times vessels from different companies are using the same IP address at the same time. In my test setup I am now using dynamic clients with sql and rlm_raw on FR 2.1.11. I am extracting the NAS-Identifier within 'dynamic-clients': if ("%{sql: SELECT nas_identifier FROM phs_nas WHERE nas_identifier = '%{raw:NAS-Identifier}'}") { This works fine as only a nas with the correct NAS-Identifier will be allowed. After the first Access-Request the IP address of the NAS is added to the (memory resident) client/nas list. In my sql nas table I like to use the NAS-Identifier instead of the IP address (at least that is my intention). The standard scenario is working fine using the NAS-Identifier: rad_recv: Access-Request packet from host 192.168.25.215 port 49481, id=39, length=222 Wed Jul 27 04:25:18 2011 : Debug: server dynamic_client_server { Wed Jul 27 04:25:18 2011 : Debug: rlm_raw: (raw_xlat) Wed Jul 27 04:25:18 2011 : Debug: rlm_raw: NAS-Identifier = myTestID123 Wed Jul 27 04:25:18 2011 : Debug: rlm_sql_mysql: query: SELECT nasname FROM phs_nas WHERE nasname = 'myTestID123' ... Wed Jul 27 04:25:18 2011 : Debug: } # server dynamic_client_server Wed Jul 27 04:25:18 2011 : Debug: - Added client 192.168.25.215 with shared secret HereIsMySharedSecret1 rad_recv: Access-Request packet from host 192.168.25.215 port 49481, id=39, length=222 User-Name = " myuser" NAS-Identifier = "myTestID123" ... Wed Jul 27 04:25:19 2011 : Info: ++[exec] returns noop Sending Access-Accept of id 39 to 192.168.25.215 port 49481 Here comes the problem! Now radiusd receives a request from a different client/NAS, but with the same IP address: Since the IP is already in the memory resident client/nas list, there is no need to search the database again. The different NAS-Identifier and different shared secret is ignored and the Access-Request is accepted. rad_recv: Access-Request packet from host 192.168.25.215 port 53237, id=42, length=222 User-Name = "thisUser " NAS-Identifier = "myTestID456" ... Sending Access-Accept of id 42 to 192.168.25.215 port 53237 While the request (id=42) is getting through, the reply is using a different shared secret, the one found in the first access-request (id=39) and the reply will therefore not be accepted by the nas and the NAS log shows: RADIUS server is not responding My conclusion: I like to use the e.g. NAS-Identifier for a unique identification of a client/nas instead of the IP. I do not want to change anything on the client side (e.g. vpn etc.). All client/nas have to use unique NAS-Identifiers and Shared Secrets which is easy to achieve during setup. Any hints using FreeRadius with the NAS-Identifier in this context are appreciated! Or if FreeRadius cannot support this, are there other Radius server which could do this job? Is there by chance anywhere Freeradius developer documentation available or is the 'documented' source code the documentation? Thank you!
Gunther wrote:
Anyhow, I still have the problem that clients using ISPs with shared IP addresses (e.g. some satellite providers etc) have to use exactly the same shared secret for all routers (nas) despite they might be different customers.
In addition, we have clients with the nas installed on vessels and they roam between different satellite links and IP addresses. At times vessels from different companies are using the same IP address at the same time.
The only real solution is a secure transport protocol. Install FR on each system, and use RADIUS over TLS. That solves both the "re-use IP" and the "end system identity" problem.
Here comes the problem! ... While the request (id=42) is getting through, the reply is using a different shared secret, the one found in the first access-request (id=39) and the reply will therefore not be accepted by the nas and the NAS log shows: RADIUS server is not responding
Exactly. RADIUS requires a unique IP for every client.
My conclusion: I like to use the e.g. NAS-Identifier for a unique identification of a client/nas instead of the IP.
You can come up with horrible hacks, or you can use crypto.
Any hints using FreeRadius with the NAS-Identifier in this context are appreciated!
Edit the source code.
Or if FreeRadius cannot support this, are there other Radius server which could do this job?
I'm not sure that *any* RADIUS server supports this.
Is there by chance anywhere Freeradius developer documentation available or is the 'documented' source code the documentation?
All documentation ships with the server. Alan DeKok.
Alan DeKok wrote:
The only real solution is a secure transport protocol.
Trying to avoid the 'BIG' change as this would imply that all routers have to be modified and they have to support this feature.
Install FR on each system, and use RADIUS over TLS. That solves both the "re-use IP" and the "end system identity" problem.
Not a viable option really as I would have to install/maintain too many FR servers and I try to avoid the TLS overhead.
Exactly. RADIUS requires a unique IP for every client.
Yep, that is the current solution (and problem).
My conclusion: I like to use the e.g. NAS-Identifier for a unique identification of a client/nas instead of the IP.
You can come up with horrible hacks, or you can use crypto.
Working on the 'horrible hacks' ...
Any hints using FreeRadius with the NAS-Identifier in this context are appreciated!
Edit the source code.
I'll give it a try.
All documentation ships with the server.
Thought so ;-) Thanks Alan! Maybe 'FreeDiameter' will provide the functionality ... Gunther
Gunther <freeradius@caribsms.com> wrote:
[snipped]
Here comes the problem!
Now radiusd receives a request from a different client/NAS, but with the same IP address:
Since the IP is already in the memory resident client/nas list, there is no need to search the database again.
The different NAS-Identifier and different shared secret is ignored and the Access-Request is accepted.
Your pants *might* explode but a glance at the source says you could either: * set client lifetime to '-1' (means the check in main/listen.c:client_listener_find() possibly is bypassed), Alan, possibiliy unintended, made it an int and so setting it to a negative value could make the lookup expire instantly * subscribe to the school-of-commenting and comment out from main/listen.c:client_listener_find() ---- if ((client->created + client->lifetime) > now) return client; ---- Cheers -- Alexander Clouter .sigmonster says: Do not attempt this in your home.
Alexander Clouter wrote:
Your pants *might* explode but a glance at the source says you could either: * set client lifetime to '-1' (means the check in main/listen.c:client_listener_find() possibly is bypassed), Alan, possibiliy unintended, made it an int and so setting it to a negative value could make the lookup expire instantly * subscribe to the school-of-commenting and comment out from main/listen.c:client_listener_find() ---- if ((client->created + client->lifetime) > now) return client; ----
Thanks! Will give it a try (after checking what I am skipping). No explosion yet. Currently refreshing my gdb knowledge in listen.c Cheers
participants (3)
-
Alan DeKok -
Alexander Clouter -
Gunther