4.6.8. Troubleshooting

4.6.8.1. Wired Workflow

In the following diagram we can see the flow that we should follow when identifying problems in the use case of Guest using Wired Workflow:

Guest-Wire-Troubleshooting-diagram.png


As we can see, the first thing that happens when connecting the User Device to the network is the MAB authentication from the Network Device.

Since this is the first time connecting, the policy evaluation determines that the user should access the “REGISTRATION” VLAN.

Verify RADIUS authentication (MAB):

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

  • Alternatively, we can use the raddtest command for a higher degree of debugging.

To verify that the evaluation is carried out correctly, we can review the poleval log:

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

When the user tries to access a website, the poisoned DNS server will redirect him to the captive portal. We can check the DNS (in case of using it in ON Core) in:

  • To verify if the Guest has connectivity with the OpenNAC Enterprise

tcpdump -Nnl -i eth0 host <IP HOST>

  • To verify if the dnsmasq is listening.

netstat -anp | grep 5

At this point the user can perform the captive portal flow.

The logs that we must review if there is any problem at this point are the following:

Captive portal log:

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

Note

Remember to check this log on the machine where the captive portal is installed.

API log:

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

Once the captive portal workflow is done, a re-evaluation of the session will be performed and the device should access the corresponding VLAN.

For the re-evaluation, a TogglePort will be performed, so we must review the log:

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

4.6.8.2. Wireless Workflow using SMS

In the following diagram we can see the flow that we should follow when identifying problems in the use case of Guest using wireless (WLC) workflow:

guest_flow_wireless_sms.png


As we can see, the flows are very similar.

The main difference is that in this case, there is no need to use a poisoned DNS. This is because the WLC may restrict network access by applying ACLSs (previously defined) before allowing full network access.

To check if there is any error when making the SMS, we must review the captive log:

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

Note

Remember to check this log in the machine where the captive portal is installed.

Once the flow has been carried out correctly, if it is not possible to access the network, we can review the RADIUS logs (ON Core) to verify its operation:

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

Note

Since much of the flow happens between the WLC and the client, it might be interesting to review the WLC logs to identify possible failure points.

4.6.8.3. Soponsor - Guest Mail Validation

First Step validate the traffic in interface

  • To verify if the Guest has connectivity with the OpenNAC Enterprise.

tcpdump -Nnl -i eth0 host <IP HOST>

If ON Core uses other interface, replace eth0 for the correct interface.

  1. To verify the Postfix view maillog

tail /var/log/maillog

  1. To verify if the dnsmasq service is enabled for autostart after reboot.

chkconfig --list dnsmasq

  1. To verify if the dnsmasq is listening.

netstat -anp | grep 5