AXL Software® RADIUS Client and Server trouble shooting guide">
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.
Can you ping the RADIUS server from your workstation? Basic connectivity is important.
Has the server been configured to accept connections from your IP address? The server
must have your machineís IP address in its NAS (Network Access Server) list. Your
RADIUS client acts as a NAS.
This must be checked at the server end. If the clientís computer is multi-homed you
must either bind your client to a particular IP address or determine which address is
picked up and make that the NAS address at the server.
Server ports, standard or non-standard?
The protocol specification requires that the authentication port must be 1812 (1813 for
accounting). There are still many servers using an earlier, now out of specification, port
of 1645 (1646 for accounting). Windows RADIUS server (IAS) is one of the
offenders, and it isn't old enough to justify using the older ports.
If you're not sure try both authentication ports.
Is the serverís NAS configurationís secret the same as your clientís
Each NAS can have it's own secret, so be sure the server's NAS entry's secret is the same,
and are usually case sensitive, hexadecimal or binary. Mismatched secrets are the best way to avoid a
We here it all the time - "They're exactly the same. I've checked again and again!"
Continue to argue with the computer - you may convince it.
way to check is to try PAP authentication. The password will be
encoded using the shared secret. The server's debug log may show the
decoded translation of the password - if it looks like junk the secrets
Common errors - a space in of one of the secrets,
invisible characters may be embedded, a '1' or 'l' - lots of typing
(and cut'n paste) mistakes happen.
Maybe the wrong NAS on the server was configured.
Maybe it's a different character set on each machine.
Maybe the database re-interprets certain characters.
This list could be endless but your patience is not. Go back to step one or find the problem..
The RADIUS server needs the NAS's IP address configured in order to accept connections.
servers are configured to accept connection from known NAS's by IP
address. If the client's IP is not known to the server it will
drop the packet.
A server may be configured to accept dynamic addresses - you may have to set this up.
The server will silently drop any packet not from a known IP address.
Slow response from the server or network
This is a real timeout error. Pinging the remote server will reveal a slow connection. Try
increasing the timeout to a larger value, perhaps 20 seconds or even longer. The RADIUS
server may be overloaded or your packet may have to cross a WAN to reach it. Or proxy
RADIUS servers are between your client and the target server. The ping time will not show
RADIUS server latency.
Proxy server problems.
If the User-Name attribute resembles an email address, e.g. email@example.com you may be using a proxy server. When proxies are present each one: A)
will slow down response time, B) can loose your packets. Increase the timeout value and
Specific to the AXL RADIUS Client:
AXL Software® RADIUS client can also indicate a BAD_PACKET response
(value of 0). The reason for the error can be extracted from the
client either as a number or a string. Here are some of the
reasons (also common to other RADIUS clients that may not report these
The returned authenticator is incorrect. This can mean that the shared secret used by the
client doesn't match the server's secret. With MS-CHAP and other authentication methods
involving challenge attributes the authentication may succeed but the returned
authenticator is incorrect with mismatched secrets. PAP authentication will always fail
under these circumstances.
The packet identifier of the received packet isn't the same as the request identifier.
The User-Name is missing or null when using any of the authentication() methods.
The reply packet's attributes are corrupt.
The Message-Authenticator attribute, if present, is incorrect.
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
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.
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
A response packet is received:
The client accepts it. Great - everything is finally working.
The client rejects it - connectivity is good and you have ordinary RADIUS problems.
The response is Access-Accept
authentication may have worked but the secret is
incorrect. Authentications other than PAP use one way encodings
that do not depend on the RADIUS shared secret so may work. However the
client also checks the signature contained in the packet and it fails
if the secret is wrong (or the response is an attack - rare).
IP address in the response packet does not match the IP address of the
request packet. This happens if the server is multihomed and receives
the packet on one interface and sends the response on another. Fix the
The response is Access-Reject - the secret is
wrong in the case of PAP authentication. The name or password is wrong
with other authentication methods.
No response packet is received:
The server may not return a packet because it does not recognize the client's source address - check the server log.
serve may reject the Message-Authentication attribute's value - the
shared secret is incorrect. The server will drop this packet - check
the server log.
There may be a firewall blocking RADIUS packets
this case use a sniffer on each side of every firewall the packet must
traverse. When you stop seeing request or response packets passing to
the other system you have a firewall problem. Fix it.
Virtualization - Virtual Server subtleties
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
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.
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 - AXLSoftware.com Corrections and additions welcome at the support page on AXLSoftware.com.