Troubleshooting network access control

In this topic, you will learn how to troubleshoot common issues with network access control, identify potential root causes, and review key areas to investigate before submitting a support ticket.

If one or more devices lose access to a network protected by Portnox Cloud, start by checking the areas where problems most often occur. Every environment is different – with different settings, integrations, NAS devices, and components – so this is not a strict step-by-step guide. Use these checks as a reference and adjust them to fit your own setup. Skip any steps that do not apply to components you are not using.

This section is mainly for cases where the system was working correctly but stops working unexpectedly. It helps you review the likely causes and narrow down where the problem might be.

You can also use these checks when adding something new – for example, new devices, a new NAS, or a new site. Even if everything else is working well, new additions can cause problems. Use this list as a flexible starting point to investigate and find possible causes before submitting a support ticket.

Ask the Portnox Docs AI bot by clicking on the Help icon in the bottom-right corner.

The Portnox AI bot has access to all documentation and may already have information about your issue. If not, it will suggest topics most likely related to your problem. Be sure to describe your issue using full sentences and include as many details as possible.

Check the Portnox Status page for intermittent problems, updates, or known issues that may affect your environment.

If there is a network issue affecting your entire environment, it may also impact all of Portnox Cloud. Check the status.portnox.com website to see whether there is planned maintenance or an outage that may affect your service.

Check if any other Portnox Cloud administrator made changes in the Cloud configuration that could cause issues.

To access the administrator activity log, click on: Troubleshooting > ACTIVITY LOG.

Check the Alerts page for relevant alerts on affected devices, as they often provide information about the cause of a problem.

If a device cannot connect to the network, but the NAS that the device connects to can connect to Portnox Cloud, there is likely to be an alert on the Alerts screen with detailed information about the failure. It may be possible to solve the issue or learn where to investigate further on the basis of detailed information in this alert.

For the full list of possible alerts and their meanings, see the following topic: List of Portnox Cloud alerts.

Check for changes in the user or device repository, such as group reassignments or similar updates.

In most configurations, Portnox Cloud uses your existing authentication repository, such as Entra ID or Google Workspace, to assign network access rights. This access is most commonly based on groups defined in the repository, which are mapped to Portnox Cloud groups. If a user or device that is already in the repository is, for example, moved to another group, their network access rights are likely to change. Larger changes to the repository structure may affect a greater number of users and devices.

Check Portnox Cloud group assignments and group configuration to ensure devices are in the correct groups and have proper connectivity permissions.

Check that the device account in your authentication repository is correctly synchronized with the appropriate Portnox Cloud group. If it is, review the Portnox Cloud group configuration to ensure all options are set correctly. A common issue when setting up new device groups is incorrect configuration, which can prevent devices from accessing specific Wi-Fi network SSIDs, for example.

Keep in mind that major network changes, such as modifying the SSID of a network protected by Portnox Cloud, require corresponding updates in Portnox Cloud.

Check for changes in UEM/MDM software, including configuration profiles and group assignments that affect device policies.

In many configurations, network access is granted to users and devices based on certificates issued by the Portnox SCEP server, while the issuance process is ultimately managed by your existing UEM/MDM software, such as Intune. Changes to policies or configurations in the UEM/MDM software may result in the removal of critical certificates or reconfiguration of network interfaces, making it impossible for devices to connect to the network. Check your UEM/MDM logs for any changes made by other administrators.

A common issue we have observed is multiple agents conflicting with one another by attempting to configure network interfaces according to their own policies. This may occur, for example, when using AgentP alongside Microsoft Group Policy. When using AgentP, ensure that it is the only solution managing network adapter configurations.

Check firewall settings for any new rules or modifications that could block Portnox Cloud communication.

One of the most common problems affecting entire environments is changes to firewall settings, which may impact RADIUS communication, AgentP, LDAP Broker, local RADIUS/TACACS+ instances, or Portnox Docker containers. Depending on which of these components is affected, review the firewall requirements in the documentation and verify that no recent rule changes are blocking the required traffic.

A common firewall misconfiguration is allowing traffic based on current Azure IP addresses. Microsoft may change or add IP addresses associated with their existing FQDNs at any time. Because Portnox Cloud runs on Azure infrastructure, such changes can disrupt connectivity. We strongly recommend configuring firewall rules based on FQDNs. If that is not possible, run periodic scripts to update firewall rules to reflect any IP address changes made by Microsoft.

Check for changes in NAS configuration, including firmware updates that may require RADIUS or other service adjustments.

In RADIUS communication, the NAS device is the component that communicates directly with the Portnox Cloud or local RADIUS server and grants or denies network access to devices. Any changes to the NAS configuration may prevent it from contacting the RADIUS server, which can block all future authorization requests from devices through that NAS.

Because NAS configurations are often complex, changes made for other purposes may unintentionally affect RADIUS settings. Check the NAS logs, enable debugging if available, and consult the manufacturer’s documentation to ensure that any changes made by you or another administrator have not disrupted existing connectivity.

When setting up NAS devices for the first time, ensure they are running the latest firmware. We have encountered several devices where a firmware update was required to enable proper operation with RADIUS servers and, consequently, with Portnox Cloud.

For known problems, see the following topic: How to troubleshoot issues related to NAS devices and Portnox RADIUS.

Check physical network connections, including Ethernet cabling and Wi-Fi signals, for proper connectivity or potential interference.

Although unlikely, physical changes in the infrastructure can prevent specific devices from accessing the NAS. Check for any cabling changes, loose Ethernet cables or connectors, and potential Wi-Fi interference to rule out this possible cause of connectivity issues.

Check device configurations and certificate validity if devices are manually configured, for example using credential-based authentication or the self-onboarding portal.

If your devices are configured manually, and not managed by UEM/MDM software or AgentP, check for any changes to the network adapter configuration or certificates that may affect RADIUS connectivity. Open the network adapter settings and ensure they match the guidelines in our documentation.

Additionally, for scenarios such as using the self-onboarding portal, check the certificate stores on your operating system to verify that the access certificate has not been removed or expired. Note that Portnox Cloud cannot manage certificate expiration on manually configured devices without AgentP or UEM/MDM software.

Check system clock settings on all devices, including NAS and local Portnox components, ensuring the correct time zone and synchronization.

One of the most common causes of issues with synchronization, connectivity, and certificates is incorrect clock settings on supplicant devices and NAS devices. Ensure that they are synchronized with an atomic clock or, if that is not possible, that they are set to the correct date and time and checked periodically for discrepancies.

For example, if a supplicant device is set to an incorrect year, such as 1970 (the default on some IoT devices), it will treat the Portnox RADIUS certificate as invalid, since the certificate was issued much later. Even small time differences can cause problems with LDAP synchronization and direct connectivity.

Check AAA logs in Portnox Cloud for detailed information about authentication attempts and potential causes of failures.

Click on: Troubleshooting > AAA LOGS to access the AAA logs. Select the time frame and load the logs to your tenant to inspect them. Look for failed attempts corresponding to the time when your issue occurred. If there are no AAA logs for these attempts, this indicates a firewall or other connectivity problem, because if the NAS device can reach the Portnox Cloud RADIUS server, AAA logs will be generated for each attempt and can provide details about the cause of the problem.

If you cannot analyze AAA logs yourself, export them and attach them to your support ticket. Note that AAA logs consume significant storage, so older logs may no longer be available for support engineers.

Check packet captures, using Portnox Cloud capture tools and third-party analysis tools as needed.

Packet captures let you record the full traffic between your NAS device and Portnox Cloud, providing more detail than AAA logs and helping identify issues such as packet fragmentation that can affect certificates. To capture packets, click on: Troubleshooting > PACKET CAPTURE and follow the instructions in this topic: Packet captures. An empty packet capture usually indicates connectivity problems between your NAS device and the Cloud RADIUS servers, caused by either firewalls or NAS configuration issues.

If you cannot analyze packet captures yourself, attach them to your support ticket. Packet logs consume significant storage, so older logs may no longer be available for support engineers.

Check whether you can connect to the Cloud RADIUS server using third-party tools.

Follow the steps in this topic: Testing Cloud RADIUS connectivity. If a test machine cannot connect to the Portnox Cloud RADIUS servers using third-party tools, this indicates a potential firewall or routing issue.

Check device logs, such as Event Viewer, for network connectivity or configuration issues.

Check your operating system logs, such as the Windows Event Viewer, for any entries indicating network connectivity problems. For general network troubleshooting, see: Troubleshooting access to networks protected by Portnox Cloud.

Check AgentP logs if it is in use, following the AgentP troubleshooting steps to collect and analyze logs on all platforms.

To learn about common problems with AgentP, see the following topic: How to troubleshoot errors when installing AgentP. Some issues listed there reference specific log entries; to access AgentP logs, see: How to collect AgentP logs for support.

Check the status of the Portnox LDAP Broker both in Portnox Cloud and on the local machine running the Broker, following the Broker troubleshooting guide.

To check the status of your broker(s), click on: Settings > Authentication Repositories > DIRECTORY INTEGRATION SERVICE > Directory domains. Then, follow this topic for detailed troubleshooting: How to troubleshoot problems with LDAP Broker.

You can also access the broker logs and events, see: Where to find the LDAP Broker logs and status.

Check local RADIUS or TACACS+ container/VM status if in use, both in Portnox Cloud and in any third-party environments such as Azure.

To check the status of your local RADIUS or local TACACS+ instances, click on: Settings > Services > LOCAL RADIUS SERVICE > Local RADIUS instance or Settings > Services > LOCAL TACACS+ SERVICE > Local TACACS+ instance. Then, follow these topics for detailied troubleshooting: