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?  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 NT’s RADIUS server (IAS) is one of the offenders, and it isn't old enough to justify using the older ports. Livingston is an example of an older server using obsolete port numbers.
  
  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.  Mismatched secrets are the best way to avoid a connection.

• There are three ways of identifying your connection to the RADIUS server.
  
  The server may be very lax and simply accept any packets from a known NAS address. This is uncommon, but the easiest setup for testing.
  
  Many servers also require that either a NAS-IP-Address or the NAS-Identifier be correctly set in the client. The NAS-IP-Address attribute must contain the correct four octets of the NAS address. This address must match the IP address of the client machine as well as the NAS address in the server configuration.
  
  Alternatively the NAS-Identifier will contain a string with the NAS’s name as configured at the server.  Check your server's configuration to see if this is true.
  
  It’s unusual and out of specification for a server to require both attributes. Indeed, it may violate a RADIUS server’s rules and cause dropped packets.
  
• 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@zither.com, or even mjl@zither 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 time and retry count.
  
• Specific to the AXL RADIUS Client:

  This 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 the reasons:
  
  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.
Other attributes may also be required for specific types of authentication (especially if you’re emulating a piece of hardware for, lets say, a PPP connection) but in general you should see a rejection if such attributes are missing. Of course, there are no guarantees this will be the case with any particular server.

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.