Windows Radius Test Client

0 views

Skip to first unread message

Landerico Benson

unread,

Aug 3, 2024, 3:57:15 PM8/3/24

to oneminti

RADIUS servers are widely used by internet service providers (ISPs) and public Wi-Fi providers to manage user credentials, enforce policies, and collect usage data. Enterprises and corporate networks also use RADIUS servers to authenticate and authorize users to access their networks.

According to Grand View Research, the global server market was valued at $83.66 billion in 2020 and is expected to grow at a compound annual growth rate (CAGR) of 7.8% from 2021 to 2028. The increasing adoption of cloud computing, mobile devices, 5G, IoT, and network technology drives the need for reliable RADIUS servers and testing tools.

NTRadPing is a free RADIUS client program. NTRadPing is a robust, easy-to-use tool for testing installations of your RADIUS servers. Through NTRadPing, you can run simple authentication and accounting simulation requests.

radclient can test different RADIUS authentication methods, such as PAP, CHAP, MS-CHAP, and EAP. It can also use the RADIUS dictionary file and display the response code and attributes from the RADIUS server.

One of the basic features of RADIUS server testing and monitoring tools is the ability to send packets to a RADIUS server and receive replies. This can help test the initial configuration of the server as well as verify the changes made to the settings. The tools can send different types of packets, such as authentication, accounting, status, and disconnect, with various attributes and values.

Some RADIUS server testing and monitoring tools can also monitor user experience for network access. This can help ensure users are not facing any problems or delays while accessing the network via a VPN, dial-up, wireless, or Ethernet connection. The tools can track various metrics, such as remote access requests, request completions, timeouts, invalid inputs, and more.

Finally, some RADIUS server testing and monitoring tools can also support multiple location testing. Using this feature, RADIUS testing tools can send packets from different locations or regions to test and monitor different servers or networks. This can help ensure test accuracy and reliability, as well as identify any geographic or network-related issues that may affect the performance or availability of the server or user experience.

But RADIUS servers are not immune to failures, errors, or cyberattacks. If a RADIUS server goes down or becomes compromised, it can cause severe disruptions to network operations and security. Therefore, RADIUS server testing and monitoring tools are critical to operating reliable and safe RADIUS networks. Using these tools, users can configure, manage, maintain, detect, and resolve any issues with RADIUS infrastructure before they affect their business-critical operations. But how do you choose which RADIUS testing tool is the best fit for your business?

To choose the best RADIUS server testing and monitoring software, decision-makers need to consider several factors. These include factors such as the size and complexity of your RADIUS infrastructure and the level of customization and flexibility your monitoring scenarios require.

I am setting up Sophos XG Wireless for the first time, and having some trouble with Radius. I have a ticket open with Sophos support, but wanted to reach out to the community to get their take on the issue. I followed the instructions by Sophos for setting up the Radius server on my DC, and adding it as an authentication mechanism under the "Services" settings for "SSO using RADIUS accounting request. The test fails, but gives little information as to why. Are there any logs I can transfer from the XG to give me more information on what I am missing in the radius setup?

In my experience the Sophos XG use unencrypted usename / password for the tests. In your RADIUS server in the authentication protocols enable CHAP/PAP iirc. Windows will pop up a warning message but just say yes. Run the test again for RADIUS authentication. You may have to try a couple of username format but it' mostly been successful with just a username

I enabled basically ALL the authentication methods on the radius server but still get the same problem. Radius is a whole basket of confusing so I suspect it is something to do with a setting on the radius server itself. One setting I don't know what to configure with is the "domain" box, is that needed?

The "domain" box is not filled in ours, the "Group Name" box is though and it just using "DOMAINNAME\Domain Users" this should probably be reduced but Sophos XG groups are confusing and limited i've found.

We use Windows 2019 NPS for our RADIUS and to get L2TP VPN working the Connection Request Policy Properties Settings Specify a Realm Name Attribute has to be modified. The attribute to modify is User-Name. In Find use ^DOMAINNAME\\ Replace With: leave blank.

It does work but my experience with Sophos and Windows RADIUS is that they are very pedantic in how they work together, there's no room for fudging or "close enough" Oh, and i never got it to work on Windows 2012R2, only 2019, go figure......

I tried adding the settings for my domain similar to yours, but still no avail on the test. I am also on Server 2019 so I was hopeful, but it is still a mess. I will keep trying, any other suggestions are certainly appreciated while I wait for Sophos Support.

I was using the XG's actual IP address (management IP) as the client address in NAP. It was Wireshark that showed no RADIUS packets were getting to the NPS server from this address. I was using the ip address of the XG in the RADIUS Clinet list

After some work with Sophos Support we were able to get Radius working, almost all of the issues were on the Radius server side because it is an old confusing technology. What we found is that you basically need a very basic Radius set up to get it going. The "group name attribute" still confuses me, but we have it set to our domain without the qualifier after the "." and it is working. If anyone else is having trouble with getting started, send me a direct message and I would be glad to share our settings/experience.

We have Clearpass 6.3.1 and Aruba 7210 with 6.4 on it. We are starting to see these Timeouts more frequently in Clearpass. It is not completely stopping users from connecting, it just interupts their connection for what seems like a random amount of time.

I saw a previous thread about this where the users were constantly receiving this Alert, but since mine doesn't seem to be happening all the time I am wondering if I have a setting somewhere that I'm missing. It would be helpful if someone could point me in the right direction to at least troubleshooting the issue.

How would you recomend overcoming trust issues? We have a Self Signed Cert for our RADIUS Cert, which obviously is not trusted everywhere. The majority of hosts that connect are not on our domain, so we cannot make it a Trusted CA by GPO, is there a preferred method for adding that trust quickly and/or without touching Every computer that has the issue?

So we have a self signed Cert on our Clearpass for the Radius cert. I can export this cert and install it on a Windows machine as a Trusted CA, Which works well for accepting the cert without popping up asking if the server is trusted on the client.

Sorry to double post but here is an update to the way I notice things happening. Generally if the computer is going to have an issue on this network connection it happens in the first few minutes of connection.

I am having an issue with onboarded MacBooks authenticating with EAP-TLS to ClearPass 6.3. This issue appears to be isolated to MacBooks running 10.8 and 10.9 - other onboarded devices (iPads, iPhones, Android) have not exhibited this issue.

The MacBooks are frequently failing to authenticate with EAP-TLS after being onboarded. ClearPass shows the authentication request as a timeout, giving the Error Code 9002 and the message "Client did not complete EAP transaction".

Packet capture shows that the initial EAP identity request and respone go through, the AP then sends the EAP-TLS/Start message and the MacBook does not respond with the TLS Client-Hello. Shortly after, the MacBook sends a disassociate frame. The frustrating thing is that often the MacBook will then immediately reassociate and perform a successful EAP-TLS authentication!

I am having this issue not only with Macbooks but also Windows 8.1 clients. I do not Onboard though. I too noticed the same packet sequence happening though now that I've gotten a few test machines to behave similarly.

It's possible that the Cert may be the issue because I am using the Aruba Cert that is untrusted. My issue seems to happen when I setup wifi profiles instead of just connecting to the wifi like normal. Or randomly with Mac's.

I've actually seen a similar issue with a client using OSX. After much troubleshooting we found that it was the combination of having bluetooth connected and trying to associate to ClearPass using EAP-TLS. As soon as we disabled bluetooth on the MacBook Pro the client was able to connect.

After working with Apple Support, we found that Mac clients which had been Onboarded (Single SSID onboarding) still had the PEAP credentials for the SSID in their Login keychain and that was causing an issue with the OS X supplicant. Deleting the 802.1X password (PEAP credentials) from the keychain resolved the issue.

RADIUS test client is an easy to use tool to simulate, debug and monitor most RADIUS and Network Access Servers (NAS).
As a test client simulate RADIUS authentication, accounting and CoA/Disconnect requests for multiple devices and usage scenarios.
As a debugging tool raw RADIUS attribute packet information from your NAS or RADIUS server is decoded into an easy to read display or stored for later use in a profile.
As a monitoring tool track hundreds of RADIUS servers, keep uptime statistics and send email/SMS pager notifications should a server become unreachable.