4.2.8. Troubleshooting

In order to troubleshoot the UNAC use case, we have considered the following sections. Carefully review the topics to see if they can solve your problem.

4.2.8.1. Troubleshooting Process

In the following diagram, we can see the flow that we should follow when identifying problems in the use case of UNAC.

At the connectivity level, we can verify that the requests are reaching OpenNAC Enterprise using a tcpdump on the authentication and accounting port:

tcpdump -i any port 1812 or port 1813 -v

When reviewing the flows, it is important to see the system logs to be able to identify where the problem is. Some of these logs are:

• RADIUS Logs

Logs related to the RADIUS module (authentication failures, wrong shared-key, etc.):

tail -100f /var/log/radius/radius.log

• API log

Here we can see information about the calls to the Core API, for example the execution of synchronous plugins, evaluation of policies, etc:

tail -100f /var/log/opennac/opennac-api.log

• Poleval Log

Logs related to the evaluation of policies defined in ON Core:

tail -100f /var/log/opennac/opennac-poleval.log

• Jobs Log

Here we can see information about the jobs to be executed by the Core, for example the execution of asynchronous plugins:

tail -100f /var/log/opennac/opennac-job.log

• Queues Log

Here we can see information about the ON Core execution queues, for example the automatic post-REEVAL Toggle Ports:

tail -100f /var/log/opennac/opennac-queues.log

4.2.8.1.1. Debug radius Module

To execute a more extensive debug of the radius module, we can execute the command:

raddebug -t0

This will show us a real-time debug of the radius module and its execution.

If we know any parameter of the connection that we want to debug, we can add it as a filter as follows:

raddebug -t0 -c 'Calling-Station-Id == "00-01-02-03-04-05"'

4.2.8.2. MAB Auth Flow

This is the flow of a MAB type authentication. We will have to delimit where the problem exists by doing a complete follow-up of the standard flow.

1. The User Device (UD) triggers a link-up event when it is connected to a switch port. At this moment, the port is in an unauthorized state.

2. After the EAPOL timeout, since the UD has no supplicant, the Network Device (ND) sends a RADIUS authentication access request to an OpenNAC Core server (CORE), using the UD MAC address as the user.

3. The CORE server processes the RADIUS access request by doing a policy evaluation (poleval) in order to match the request with one of the policies. As a result of the poleval, the CORE server sends back to the switch a RADIUS access accept response with the information of which VLAN must be assigned to this UD.

4. The ND changes the port state to authorized, completing the connection process.

5. The UD requests its IP address via DHCP protocol sending a DHCP Request broadcast.

6. The DHCP server answer with a DHCP response packet assigning an IP address to the UD.

7. The ND sends to the CORE server a RADIUS accounting packet which triggers an IPMAC event.

8. In Network Layer (L3) the DHCP request broadcast is also forwarded to the CORE server in order to generate IPMAC events which are useful for profiling purposes.

4.2.8.3. Supplicant Flow

This is the flow of a Suplicant type authentication. We will have to delimit where the problem exists by doing a complete follow-up of the standard flow.

1. The User Device (UD) triggers a link-up event when it is physically connected to a switch port and starts to send EAPOL packets. At this moment the port is in an unauthorized state.

2. The Network Device (ND) sends a RADIUS authentication access request to an OpenNAC Core server (CORE) for the user or machine account.

3. The CORE server processes the RADIUS access and authenticates the user credentials against the Active Directory domain (AD).

4. As a result of the poleval, the CORE server sends back to the switch a RADIUS access accept response with the information of which VLAN must be assigned to this UD.

5. The ND changes the port state to authorized, completing the connection process.

6. The UD requests its IP address via DHCP protocol sending a DHCP Request broadcast.

7. The DHCP server answer with a DHCP response packet assigning an IP address to the UD.

8. The ND sends to the CORE server a RADIUS accounting packet which triggers an IPMAC event.

9. In Network Layer (L3) the DHCP request broadcast is also forwarded to the CORE server in order to generate IPMAC events which are useful for profiling purposes.