Hi! We're trying to migrate from FreeRADIUS 2.x with radsecproxy to FreeRADIUS 3.x and encountered two major problems. The first being that FR doesn't seem to send any replies to the client when it receives Access-Request messages via RadSec. At least we're not seeing the typical "Sending Access-Accept/Access-Reject …" messages in the debug log. The last message is always something like "Debug: (0) Auth-Type = Accept, accepting the user" but nothing regarding a response follows. We suspected SSL errors but don't find anything suspicious in the logs (server and client). The second problem is that we don't find any hints in the docs on how to configure FR 3.x to listen to both auth and acct using RadSec on port 2083. For instance: When the server receives an Accounting-On packet, we're seeing the following line in the log: Invalid packet code 4 sent from client test port 3065 : IGNORED We're using the latest git HEAD. I'd be very grateful for some pointers. (And sorry if they're blatantly obvious to you.) Thanks, JB
JB wrote:
The first being that FR doesn't seem to send any replies to the client when it receives Access-Request messages via RadSec. At least we're not seeing the typical "Sending Access-Accept/Access-Reject …" messages in the debug log. The last message is always something like "Debug: (0) Auth-Type = Accept, accepting the user" but nothing regarding a response follows. We suspected SSL errors but don't find anything suspicious in the logs (server and client).
I thought that was fixed... IIRC, the *debug* log didn't show anything, but it still sent packets. I'll see if I can figure it out.
The second problem is that we don't find any hints in the docs on how to configure FR 3.x to listen to both auth and acct using RadSec on port 2083. For instance: When the server receives an Accounting-On packet, we're seeing the following line in the log: Invalid packet code 4 sent from client test port 3065 : IGNORED
We're using the latest git HEAD.
Please use v3.0.x. It's the stable v3 release. Git "master" branch will be massively butchered to fix up historical issues with the API. The code *used* to allow "auth+acct" for TCP sockets. I'm not sure when that was removed. I've added it back in, and updated raddb/sites-available/tls Alan DeKok.
Alan DeKok wrote:
JB wrote:
The first being that FR doesn't seem to send any replies to the client when it receives Access-Request messages via RadSec. At least we're not seeing the typical "Sending Access-Accept/Access-Reject …" messages in the debug log. The last message is always something like "Debug: (0) Auth-Type = Accept, accepting the user" but nothing regarding a response follows. We suspected SSL errors but don't find anything suspicious in the logs (server and client).
I thought that was fixed... IIRC, the *debug* log didn't show anything, but it still sent packets.
I'll see if I can figure it out.
That'd be great! The client didn't seem to "understand" the packets since it complained about timeouts. No additional (useful) details in the client's logs. We'll try and use ssldump or a similar tool to get more info.
The second problem is that we don't find any hints in the docs on how to configure FR 3.x to listen to both auth and acct using RadSec on port 2083. For instance: When the server receives an Accounting-On packet, we're seeing the following line in the log: Invalid packet code 4 sent from client test port 3065 : IGNORED
We're using the latest git HEAD.
Please use v3.0.x. It's the stable v3 release. Git "master" branch will be massively butchered to fix up historical issues with the API.
We just switched to v3.0.x and are now getting segmentation faults whenever FR tries to use rlm_sql. We'll take a closer look.
The code *used* to allow "auth+acct" for TCP sockets. I'm not sure when that was removed. I've added it back in, and updated raddb/sites-available/tls
Great!! Thanks a lot! Cheers, JB
JB wrote:
The client didn't seem to "understand" the packets since it complained about timeouts. No additional (useful) details in the client's logs. We'll try and use ssldump or a similar tool to get more info.
OK.
We just switched to v3.0.x and are now getting segmentation faults whenever FR tries to use rlm_sql. We'll take a closer look.
Please double-check that you're using the v3.0.x libraries with the v3.0.x server. If the v3.0.x server is using the libraries from the "master" branch, it won't work. Alan DeKok.
Alan DeKok wrote:
JB wrote:
The client didn't seem to "understand" the packets since it complained about timeouts. No additional (useful) details in the client's logs. We'll try and use ssldump or a similar tool to get more info.
OK.
This is the output of ssldump monitoring the port 2083: 1 1 0.0194 (0.0194) C>S Handshake ClientHello […] 1 2 0.0514 (0.0319) S>C Handshake ServerHello […] 1 9 1.2804 (0.0000) C>S Handshake 1 10 1.2993 (0.0188) S>CShort record Unknown SSL content type 1 1 11 1.3307 (0.0314) C>S application_data 1 12 1.3767 (0.0459) S>CShort record 1 13 10.0033 (8.6265) C>S application_data 1 14 20.0124 (10.0090) C>S application_data 1 15 30.0219 (10.0095) C>S application_data 1 16 40.0317 (10.0097) C>S application_data 1 17 563.3482 (523.3165) C>S application_data 1 563.3491 (0.0009) C>S TCP FIN 1 563.3517 (0.0025) S>C TCP FIN You can see the Access-Request retries after 10 seconds respectively. Shouldn't there be "S>C application_data" entries? Can it be that FR really doesn't send anything back or am I interpreting this the wrong way? Anyway, we ruled out the firewall by shutting it down completely. We tested with a fresh build using only the "default" and "tls" sites. We just added our certificates and clients. Logins without RadSec work fine using the same clients. Radsecproxy also works fine using the same clients and certificates.
We just switched to v3.0.x and are now getting segmentation faults whenever FR tries to use rlm_sql. We'll take a closer look.
Please double-check that you're using the v3.0.x libraries with the v3.0.x server. If the v3.0.x server is using the libraries from the "master" branch, it won't work.
It seems that our repository was indeed mixed up. We cleaned up and cloned the branch v3.0.x again and the segfaults stopped. (Instead, we saw a talloc error followed by an abort once but failed to save the logs. We will post as soon as this happens again.) Cheers! JB
JB wrote:
You can see the Access-Request retries after 10 seconds respectively. Shouldn't there be "S>C application_data" entries? Can it be that FR really doesn't send anything back or am I interpreting this the wrong way?
It doesn't send anything back. I've pushed a fix. Alan DeKok.
We just switched to v3.0.x and are now getting segmentation faults whenever FR tries to use rlm_sql. We'll take a closer look.
Can we get a backtrace? -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
JB