4.6.8. Troubleshooting

This troubleshooting guide outlines the steps and key log files to review when identifying problems with Guest workflows in a network using both wired and wireless connections.

4.6.8.1. Wired Guest Workflow

The following diagram displays the flow to follow when identifying problems in the use case of a Guest using the Wired Workflow:

Guest-Wire-Troubleshooting-diagram.png


When the User Device connects to the network for the first time, the Network Device initiates MAB authentication.

Since this is the user’s first connection, the policy evaluation determines that the device should be placed in the “REGISTRATION” VLAN.

  • Verify RADIUS authentication (MAB)- To confirm MAB authentication, check the RADIUS logs:

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

  • Alternatively, for more detailed debugging, use the raddtest command.

  • Policy Evaluation Logs - To verify that the policy evaluation is working correctly, inspect the poleval log:

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

Once the user attempts to access a website, a poisoned DNS server will redirect them to the Captive Portal. If ON Core is being used for DNS, verify connectivity as follows:

  • Verify Guest connectivity with OpenNAC:

tcpdump -Nnl -i eth0 host <IP HOST>

  • Verify if dnsmasq is listening:

netstat -anp | grep 5

At this point, the user should be able to access the Captive Portal.

  • If there are issues at this stage, review the Captive Portal Logs:

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

Note

Ensure you check this log on the machine where the Captive Portal is installed.

  • Additionally, check the API logs if necessary:

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

After the Captive Portal process is complete, a session re-evaluation occurs, and the device should gain access to the appropriate VLAN.

TogglePort Logs

During this re-evaluation, a TogglePort action is performed. Review the following log for details:

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

4.6.8.2. Wireless Guest Workflow Using SMS

The diagram below displays the troubleshooting flow for Guest using wireless (WLC) workflow:

guest_flow_wireless_sms.png


The flow is very similar to the wired workflow, with a few key differences.

In this case, no poisoned DNS is needed because the WLC can restrict network access by applying pre-configured ACLs before granting full access.

Captive Portal Logs for SMS

To check for errors when using SMS for guest access, review the Captive Portal logs:

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

Note

Ensure you check this log on the machine where the Captive Portal is installed.

RADIUS Logs

If the workflow is completed successfully but the guest still cannot access the network, review the RADIUS logs (ON Core) for errors:

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

Note

Since much of this flow involves interactions between the WLC and the client, it may also be useful to review WLC logs to identify potential failure points.