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 secret?
  
  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 connection.
  
  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.
• One 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 don't match.
• 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.
  
  
  • RADIUS 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. mjl@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 retry count.
  
  
• Specific to the AXL RADIUS Client:

  This 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 specific errors):
  

  • 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.

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.

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 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:

• 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
• The 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).
• The 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 server.
• 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.
• The 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 
• In 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

 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.