Troubleshooting

Introduction

This chapter provides hints and tips for troubleshooting the RADIUS authentication server and the RADIUS accounting server.

Troubleshooting RADIUS Authentication

Most problems are caused by skipping a step during installation. Carefully check the installation instructions in "RADIUS Server Configuration" and "RADIUS Client Configuration" to ensure that the authentication server was properly installed.

If the problem is not solved after reviewing the instructions in those two chapters, read the troubleshooting suggestions in this chapter.

Checking radiusd Daemon

Use radiusd -v to display the version number.
Make sure /etc/radiusd is running.
Make sure in the /etc/raddb directory (or wherever you specify with the -d flag) that you have the following files: dictionary, users, and clients. If you are using RADIUS menus, check the menus subdirectory.
Use radiusd -x to view incoming and outgoing packets from RADIUS.

Checking the PortMaster

Make sure that the RADIUS server is reachable from the PortMaster.
Make sure that security is on for each port:
```
Command> set all security on
Command> save all
Command> reset all
```
When security is on, the show port command displays security in parentheses as follows: (Security).
Use the show global command to ensure that the RADIUS server IP address is set on the PortMaster.
Make sure the secret set on the PortMaster using the set secret password command matches the secret in the /etc/raddb/clients file on the RADIUS server.
The PortMaster will not display the shared secret, however, you may set it again if you are not sure that it is set properly. If you update the shared secret, make sure to use the save all command to save the shared secret in the PortMaster's nonvolatile memory.

Checking /etc/raddb/users

Items in the user entries are case sensitive. Verify the spelling and case of each line of the users file. Compare keywords against the /etc/raddb/dictionary file to ensure that they are the same.
Verify that the user can authenticate with a clear text password before authenticating with Auth-Type = System or Auth-Type = SecurID.

Host Unavailable

If a Host Unavailable message is displayed after a username is entered at the login prompt, security for the port is not enabled and rlogind and in.pmd are not running on the host configured for that port. The PortMaster is attempting to do a pass-through login to a host that is not prepared to accept it.

To verify that this is the problem, enter the following command. Replace s1 with the port that you are using.

Command> show s1

Security should be displayed in parentheses, (Security). If it is not displayed, enter the following commands:

Command> set s1 security on
Command> reset s1
Command> save all

Invalid Login after 30 second wait

The PortMaster sends 10 access-requests at 3-second intervals and then displays an Invalid Login message. This message may indicate one of the following problems:

RADIUS is not running on the server. Check to ensure that /etc/radiusd is running.
The RADIUS server is not defined correctly on the PortMaster. Check the RADIUS server information using the following commands:
```
Command> show global
Command> show netcon
```
There is no entry for the PortMaster in the /etc/raddb/clients file. This may be verified by running radiusd -x. If the output of radiusd -x produces 10 access-requests with the same ID, but does not produce a corresponding access-accept or access-reject message, the PortMaster hostname is probably missing or not defined correctly in the /etc/raddb/clients file.
radiusd responses are not getting back to the PortMaster. Examine the routing table on the RADIUS server host and ping the PortMaster from this host.
The PortMaster is ignoring radiusd responses. This is a relatively rare occurrence, usually caused by one of the following:
- Multiple IP addresses for a single Ethernet interface on the RADIUS server host
- Multiple Ethernet interfaces, and the RADIUS server is replying to a request from the PortMaster on a different interface than the interface that received the request
- The source of the access-accept or access-reject packet does not match the destination of the access-request packet

Result of radiusd -x output

If radiusd -x shows more than one access-reject sent for the same ID, check the following:

Check the route back to the PortMaster; ensure that replies are getting to the PortMaster.
Check to see if the RADIUS server host has more than one Ethernet port or multiple IP addresses assigned to the same Ethernet interface.
Check for packet filters between the RADIUS server host and the PortMaster filtering out the RADIUS return packets.
On the PortMaster, use ptrace to show packets returning from the host running radiusd:
```
Command> add filter r
Command> set filter r 1 permit udp src eq 1645
Command> set filter r 2 permit icmp
Command> ptrace r
```
Note - ptrace on a PortMaster does not show UDP or ICMP packets generated on the PortMaster itself. Outgoing RADIUS access requests are not shown, however, returning packets are displayed. To turn off tracing, use the ptrace command with no arguments.

Check the source address of a packet during tracing. A multihomed RADIUS host may be using the wrong source address when replying to access-request packets.

If radiusd -x shows an access-reject right away, check the following:

Check the spelling of the username and password. The case must match exactly.
Check syslog for errors from radiusd.
Use the show table user command to verify that the user is not in the PortMaster User Table; the local User Table is always checked first during authentication attempts.
If Auth-Type = System is not working, attempt to use a cleartext password in the user entry.
If Auth-Type = System is specified on a system that has shadow passwords, ensure that radiusd is run as root in order to access the shadow passwords.
Verify the spelling, case, and syntax of the /etc/raddb/users file. If radiusd finds any errors in the user entry, it sends an access-reject message and logs an error to syslog.
Check that the shared secret in /etc/raddb/clients matches the one set on the PortMaster using the set secret command
If using PMconsole, ensure that the Return key was not pressed when the cursor was in the RADIUS Secret field of the dialog box. Pressing the Return key at this point erases the secret when the Save button is clicked.

Troubleshooting RADIUS Accounting

If the problem is not solved after reviewing the installation instructions, check the following:

Make sure the /usr/adm/radacct directory exists and that the account used to execute radiusd has write permission to this directory.
Run radiusd using the -v flag to ensure that radiusd is version 1.16 or 2.0.
Make sure that you do not have any other process bound to UDP port 1646. Kill radiusd and use the netstat -a command; there should not be anything bound to UDP ports 1645 or 1646. Start radiusd and use the netstat -a command again; radiusd should now be listening on both 1645 and 1646. Some operating systems display the sockets symbolically as .radius and .radacct rather than .1645 and .1646.
Use the show global command to verify that the IP address of the accounting host has been configured on the PortMaster. If it has not been configured, set it using the set accounting IPaddress on the PortMaster, where IPaddress is the IP address of the host running radiusd.
Check syslog (auth.warning) for error messages from radiusd. During normal use, very few error messages should appear.
Ping the PortMaster from the RADIUS server to check connectivity.
If the previous suggestions do not solve the problem, run radiusd -x on the RADIUS server host and check to determine if accounting records are displayed.

/ Prev / Preface / TOC / Overview / Server / Client / User / Menu / SecurID / Accounting / Troubleshooting /