Thanks for the advice Alan. I tried configuring radsecproxy in another server (radsec_server) which radsecproxy config pointing to my radius server who is listening at both udp 1812 and tcp 2083.After configuring radsecproxy successfully, this new server listens at udp 1812. I ran radtest in this server to localhost 1812 and it will go to radius server at 2083.Let me confirm this is the correct setup? The authentication needs the radsec_server IP address to be present in clients.conf. Although it is already present in SQL radius client table, it cannot be recognized.I think authentication request that reaches tcp 2083 are not associated with SQL client table. Did I miss to update something?  On Wednesday, 1 July 2026 at 09:56:19 pm SGT, Alan DeKok <alan.dekok@inkbridge.io> wrote: On Jul 1, 2026, at 5:00 AM, Alan Smith via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:

I am currently running Freeradius on RHEL 8.10 in a lab. It has custom site configured and make use of sql for radius client table.Customised perl module is used for the authentication. It listens on UDP 1812 and 1813. I would say it is working fine.

  That's good.

I would like to check the use of Radius over TLS on TCP 2083 for some of the clients. I update tls in sites-available and created symlink in sites-enabled. Configured the custom CA certs.It is now listening at TCP 2083. I want to test if the clients from sql be recognized. Is there like a tool NTRadping? I can test from either Windows or Linux.I do not have any device that can authenticate. Kindly advise. Thank you.

  There's a pyradius library with TLS, or you can run another RADIUS server such as radsecproxy.  For now, that's the simplest way.   Alan DeKok.

Hi Alan, I have the following debug logs. Scenario 1 - Initial setup - radsecproxy server IP is in clients table It loads clients.conf which is empty. It starts generating sql clients. I can see radsecproxy server IP address 10.0.8.130 was added by rlm_sql. rlm_sql_mysql: Starting connect to MySQL server rlm_sql_mysql: Connected to database '*' on Localhost via UNIX socket, server version *, protocol version * rlm_sql (sql): Processing generate_sql_clients rlm_sql (sql) in generate_sql_clients: query is SELECT id, ipaddress, shortname, type, secret, server FROM clienttable rlm_sql (sql): Reserved connection (0) rlm_sql (sql): Executing select query: SELECT id, ipaddress, shortname, type, secret, server FROM clienttable rlm_sql (sql): Adding client 10.0.8.130 (ce9) to mysite clients list rlm_sql (10.0.8.130): Client "ce9" (sql) added rlm_sql (sql): Released connection (0) Finally ends with below messages and starts listening. Listening on auth proto tcp address * port 2083 (TLS) Listening on auth address * port 1812 bound to server mysite Listening on acct address * port 1813 bound to server mysite Ready to process requests When I ran command radsecproxy -f -d 1 from radsecproxy server, it shows below error.  ... new connection request on TCP socket Receive - Error receiving packet: Transport endpoint is not connected Ignoring request to auth proto tcp address * port 2083 (TLS) from unknown client 10.0.8.130 port 42299 proto tcp Ready to process requests ==================================================================================== Scenario 2 - radsecproxy server IP is in clients.conf (The one in the clients table is removed) including configuration file /etc/raddb/clients.conf  client radsecproxy {         ipaddr = 10.0.0.130         secret = <<< secret >>>         proto = "tcp"   limit {         max_connections = 16         lifetime = 0         idle_timeout = 30   }  } It finally shows the ports listening message and ready.  Listening on auth proto tcp address * port 2083 (TLS) bound to server mysite Listening on auth address * port 1812 bound to server mysite Listening on acct address * port 1813 bound to server mysite Ready to process requests When I ran command radsecproxy -f -d 1 from radsecproxy server, it shows below message and so on and successfully accepted.  ... new connection request on TCP socket Listening on auth from client (10.0.0.130, 36223) -> (*, 2083, virtual-server=mysite) Waking up in 0.6 seconds. (0) Initiating new TLS session (0) Setting verify mode to require certificate from client (0) (other): before SSL initialization (0) TLS_accept: before SSL initialization (0) TLS_accept: before SSL initialization (0) <<< recv TLS 1.3  [length 0128] (0) TLS_accept: SSLv3/TLS read client hello (0) >>> send TLS 1.2  [length 003d] (0) TLS_accept: SSLv3/TLS write server hello (0) >>> send TLS 1.2  [length 0993] (0) TLS_accept: SSLv3/TLS write certificate (0) >>> send TLS 1.2  [length 014d] (0) TLS_accept: SSLv3/TLS write key exchange (0) >>> send TLS 1.2  [length 00e3] (0) TLS_accept: SSLv3/TLS write certificate request (0) >>> send TLS 1.2  [length 0004] (0) TLS_accept: SSLv3/TLS write server done (0) TLS_accept: Need to read more data: SSLv3/TLS write server done (0) TLS - In Handshake Phase (0) TLS - got 3101 bytes of data ==================================================================================== I vaguely have the idea like it is somehow treating all sql client table as UDP connection. Until I add the client in clients.conf with proto = tcp identifier, TCP incoming may not have a client record for radsecproxy server. On Wednesday, 8 July 2026 at 09:57:01 pm SGT, Alan DeKok <alan.dekok@inkbridge.io> wrote: On Jul 8, 2026, at 7:52 AM, Alan Smith via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:

Thanks for the advice Alan. I tried configuring radsecproxy in another server (radsec_server) which radsecproxy config pointing to my radius server who is listening at both udp 1812 and tcp 2083.After configuring radsecproxy successfully, this new server listens at udp 1812. I ran radtest in this server to localhost 1812 and it will go to radius server at 2083.Let me confirm this is the correct setup?

  Yes.

The authentication needs the radsec_server IP address to be present in clients.conf. Although it is already present in SQL radius client table, it cannot be recognized.I think authentication request that reaches tcp 2083 are not associated with SQL client table. Did I miss to update something?

  The server has debug output.  Read it.   Alan DeKok.

On Sat, 4 Jul 2026, at 02:33, Stefan Paetow via Freeradius-Users wrote:

I would second Alex's suggestion. I use socat in a similar fashion to run a Status-Server check for a series of hosts (given that I cannot proxy a Status-Server check).

It works fine :-)

Another favourite of mine, though it took a while for me to cotton onto the need to escape the ':' as socat's argument parser is interesting: socat -d TCP-LISTEN:1812,fork EXEC:"openssl s_client -connect 192.0.2.1\:2083 -psk_identity cli -psk ... -noservername -quiet" Cheers

Thank you Alexander and Stefan. Let me try this one also.  On Saturday, 4 July 2026 at 09:33:49 am SGT, Stefan Paetow via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote: I would second Alex's suggestion. I use socat in a similar fashion to run a Status-Server check for a series of hosts (given that I cannot proxy a Status-Server check). It works fine :-) Kind regards Stefan Paetow Federated Roaming Technical Specialist eduroam(UK), Jisc – 20 years of free Wi-Fi for the UK R&E sector email/teams: stefan.paetow@jisc.ac.uk gpg: 0x3FCE5142 For eduroam support, please contact the eduroam team via help@jisc.ac.uk and mark it for eduroam’s attention. I am not available on Mondays and Fridays between 12:00 and 15:00 London time (UTC in winter, UTC+0100 in summer). Note: I don’t expect a reply outside of your working hours, since I work internationally with colleagues in different nationalities with different religions, customs, and holidays. Reply when it is convenient for you. Jisc is a registered charity (in England and Wales under charity number 1149740; in Scotland under charity number SC053607) and a company limited by guarantee registered in England under company number 05747339, VAT number GB 197 0632 86. Jisc's registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 02881024, VAT number GB 197 0632 86. The registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800. For more details on how Jisc handles your data see our privacy notice here: https://www.jisc.ac.uk/website/privacy-notice From: Freeradius-Users <freeradius-users-bounces+stefan.paetow=jisc.ac.uk@lists.freeradius.org> on behalf of Alexander Clouter via Freeradius-Users <freeradius-users@lists.freeradius.org> Date: Thursday, 2 July 2026 at 06:42 To: Freeradius-Users <freeradius-users@lists.freeradius.org> Cc: Alexander Clouter <alex+freeradius@coremem.com> Subject: Re: radius authentication via TCP/TLS On Wed, 1 Jul 2026, at 10:00, Alan Smith via Freeradius-Users wrote:

I would like to check the use of Radius over TLS on TCP 2083 for some of the clients.

One option is to run a TLS proxy. Run in one terminal: socat -d TCP-LISTEN:1812 OPENSSL:192.0.2.1:2083,cafile=...,commonname=...,certificate=... Then run your RADIUS checks in another with: printf 'User-Name = bob\nUser-Password = hello\n' | radclient -x -P tcp 127.0.0.1 auth radsec It is a little 'ghetto', but can help you avoid writing a bunch of Python or running another RADIUS server. Cheers - List info/subscribe/unsubscribe? See https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeradius.org%2Flist%2Fusers.html&data=05%7C02%7Cstefan.paetow%40jisc.ac.uk%7C7b35b430fec24626bf0908ded7fcb016%7C48f9394d8a144d2782a6f35f12361205%7C0%7C0%7C639185677476220725%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jjJzD1M7yJg86qLLGN9RijCjwW8bKadnHRaYnh1I1UY%3D&reserved=0<http://www.freeradius.org/list/users.html> - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html