Troubleshooting access to networks protected by Portnox Cloud

In this topic, you will learn how to address the most common issues when connecting to networks protected by Portnox™ Cloud.

Why do Windows devices fail 802.1x authentication after upgrading to Windows 11 version 22H2 or later?

After upgrading to Windows 11 version 22H2 or later, some Windows devices fail to authenticate using 802.1x. These devices can still connect to the network when 802.1x is not required. In the AAA logs, the only error shown is EAP FAILED (EXPIRED) during the PEAP Phase 2 initialization.

This issue affects devices that use 802.1x for wireless or wired network access, RDP, or VPN connections that rely on insecure, password-based authentication protocols. When Credential Guard is enabled, users cannot use Single Sign-On (SSO) and must manually enter credentials for each new Windows session.

Any device with Credential Guard enabled can encounter this issue. Starting with Windows 11 version 22H2 and Windows Server 2025 (preview), Credential Guard is enabled by default on eligible devices unless it was explicitly disabled. This applies to Enterprise (E3 and E5) and Education licenses, and to some Pro licenses, as long as the device meets the minimum hardware requirements.

The root cause is that Credential Guard blocks insecure authentication protocols that use password-based authentication, because these protocols can expose passwords on the client or server. Affected protocols include Kerberos unconstrained delegation, Kerberos with PKINIT using RSA instead of Diffie-Hellman, MS-CHAP, WDigest, and NTLM v1. For MS-CHAP, WDigest, and NTLM v1, only SSO is blocked, and users can still authenticate by manually entering credentials.

Microsoft recommends moving away from MS-CHAPv2-based methods such as PEAP-MSCHAPv2 and EAP-MSCHAPv2, and using certificate-based authentication instead, such as PEAP-TLS or EAP-TLS. Credential Guard does not block certificate-based authentication.

As a temporary but less secure workaround, you can disable Credential Guard. Credential Guard does not support per-protocol or per-application settings, so it must be fully enabled or disabled. Disabling it increases the risk of stored domain credentials being stolen.

This information is based on Microsoft documentation titled Considerations and known issues when using Credential Guard. Third-party information is provided for reference only and should be independently verified. Use of such information is at your own risk.

Why are devices not assigned to the fallback VLAN when using MSCHAPv2 authentication?

When using MSCHAPv2 authentication, devices that fail authentication are rejected instead of being assigned to the fallback VLAN. This occurs even if the fallback VLAN is properly configured and works correctly with other authentication methods. This behavior has been observed on Ubiquiti access points but can also happen on other network devices.

The reason is that MSCHAPv2 handles authentication strictly. It verifies a user’s password by generating a special code called the NTKey. If the password is incorrect or the account does not exist, the authentication process fails, and the device stops communicating with the network entirely. Since the device loses connectivity during this failure, the network cannot assign it to a fallback or quarantine VLAN.

Because MSCHAPv2 enforces this strict behavior for security reasons, there is no workaround to enable fallback VLAN assignment for devices using this authentication method. The only solution is to use an alternative authentication method that supports fallback VLANs.

If you use Portnox Cloud to create a new, secure Wi-Fi network (SSID), but your Windows clients already have another network set to Connect automatically, those clients may be connecting to the old, insecure SSID, instead of the new, secure one. How to make sure that Windows prioritizes the new secure Wi-Fi network?

If Windows finds several Wi-Fi networks with the Connect automatically option turned on, the priority when attempting to connect to Wi-Fi depends on many factors such as signal strength and whether the network was accessed before. However, you can also assign manual priorities to specific Wi-Fi networks.

To do this, execute the following command on the Windows client, or use your GPO or UEM software to execute a script automatically:

netsh wlan set profileorder name="SSID_NAME" interface="Wi-Fi" priority=1

where SSID_NAME is the name of the secure Wi-Fi network that you want to connect to with highest priority.

macOS: If you reset your Mac password through Recovery Mode, you can lose access to keychains, certificates, and network profiles.

macOS encrypts the keychain with your login password. When you reset your password in Recovery Mode, the old keychain cannot be unlocked, and macOS creates a new empty keychain. Certificates stored in the old keychain become inaccessible, and services like Wi-Fi, VPN, or device management tools may stop working. Installed configuration profiles may also rely on these certificates and may fail to function.

The old keychain file usually remains in ~/Library/Keychains but is still encrypted with your previous password. If you know the old password, you can try to access the old keychain using Keychain Access to recover certificates and other data.

If the old keychain cannot be accessed, you need to redeploy the necessary certificates, configuration profiles, and Portnox AgentP if used. Follow the standard onboarding procedures for agent-based or agentless devices to restore access.

Does a change in the WAN IP affect Portnox Cloud, and what is required to keep services working?

A change in your WAN IP can affect Portnox Cloud if the tenant uses IP address restrictions for access control. This happens when the old WAN IP addresses are configured for whitelisting. You can verify this setting in Settings > Services > CLOUD RADIUS SERVICE > Cloud RADIUS Instance > Restrict access to Cloud RADIUS service. If Allow only the listed IP addresses is enabled, update the list with the new WAN IP addresses.

Apart from IP restrictions, Portnox Cloud does not require a customer WAN IP address for normal operation.

Note:

Some switches require an explicitly configured source IP address for RADIUS communication. This is usually a LAN IP address. In cases where the switch performs Layer 3 routing or operates in a DMZ, the source IP may be an external IP. Verify the NAS or switch configuration to ensure it uses the correct source IP address.