4.5.8. Troubleshooting

In the following diagram we can see the flow that we should follow when identifying problems in the Guest Use Case using the wired workflow:

byod_flow_wired.png


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

Since this is the first time connecting the network, 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.

If we have any problems with the user authentication, we can verify the connectivity with the AD with:

ntlm_auth --request-nt-key --domain=MYCOMPANY --username=testUser

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