AXL Software® RADIUS Client and Server trouble shooting guide"> RADIUS Troubleshooting

RADIUS Client / Server Troubleshooting

Only a few parameters are required by a RADIUS client when communicating with its server. If everything isn't perfect the response packets will not be sent and the stony silence of a server is no help in determining the problem. The most common problems are found in client and server configuration.

Basic checklist:

Attributes required for authentication:

User-Name, User-Password, NAS-IP-Address or NAS-Identifier and either the NAS-Port or NAS-Port-Id
Other attributes may also be required for specific types of authentication and you should see a rejection if any of the authentication attributes are missing. Initially stick to PAP and CHAP authentication methods.

A word about UDP vs. TCP:

RADIUS packets are sent using UDP/IP. This is very different from TCP/IP. Under TCP a reliable connection is established between client and server (e.g. HTTP, FTP, telnet). By reliable itís meant that a firm connection is established between the systems and the packets will automatically be resent in case of minor delivery failures.

A UDP request packet, on the other hand, is not reliable, and is manually resent if it fails to reach its destination. Detecting this problem is also manual, and relies on simply waiting too long for a response.

To complicate matters, the server may receive the packet and elect not to respond to it if its contents are unacceptable. This is done in the name of security so a cracker canít gain information from a rejected packet. Nor can you, the legitimate tester. When the server drops packets, it looks just like a response timed out.

Network Sniffers:

    The most useful tools for debugging packet prorogation are network sniffers like tcpdump, WireShark and others. These will show the request and response packets moving on different segments of the network, even within the same machine. Most can be sorted by protocol or filtered making it easier to track RADIUS packets amid the noise.

The information below is for authentication packets - they have many reasons for disappearing either responses are blocked or dropped by the server. Accounting responses must always be sent by the server and may be dropped for similar reasons (accounting packets may contain Message-Authenticator attributes).

A response packet is received:

No response packet is received:

Virtualization - Virtual Server subtleties

 Many installations are now using software virtual servers (VS) with various operating systems on their host machines perhaps with a server on one virtual server and clients on others. This opens a new set of firewall issues and client IP addresses. Network sniffers are the best tool you have.

Each virtual server will have it's own networking topology - we will assume that you've chosen NAT (Network Address Translation) for the VS's network connection type. This means that all client requests from the VS will appear as requests from a single IP address belonging to the VS. If your VS is multihomed this could require the server to be configured to accept packets from both IP addresses.

The server must be configured to accept connections from each VS rather than each client on each VS.

Naturally since there are multiple firewalls debugging RADIUS packet problems grows as well. You will have to use a sniffer on each side of the VS: inside the VS and on the outside host to verify request and response packets are passing through.

Your hunt will start within the client's VS and move outward to the host.  At some point you'll find that both the request and response packets will be visible (no promises!). This is the point where everything works. Move the test back towards the client fixing firewalls as you go.

Michael Lecuyer -
Corrections and additions welcome at the support page on