Limitation:
PoP Management has been temporarily disabled while we resolve connectivity issues that some customers experienced when swapping PoPs. While the feature is paused, PoPs cannot be selected or edited, and the retirement of unused PoPs is deferred until further notice. Existing PoP assignments remain active and unchanged.
Cloud Secure Edge Component(s):
Workaround:
No action is required to keep your existing PoP assignments active. If you require a PoP change while PoP Management is paused, contact SonicWall Support. PoP Management will be restored in a future update.
Limitation:
Domain names that resolve to multiple sets of IP addresses configured in Tunnel Policies are dropping packets, causing rejections, interruptions, or disconnections every 10 minutes.
Cloud Secure Edge Component(s):
Workaround:
Configure the necessary IP range in your Tunnel Policy instead of using domain names.
Limitation:
On all operating systems, the Cloud Secure Edge desktop app and the Cloud Secure Edge Command Center (under Directory > Devices) display the hostname as "unset" instead of displaying the system's configured hostname.
Cloud Secure Edge Component(s):
Workaround:
Step 1:
Unregister the Cloud Secure Edge desktop app on your device.
Step 2:
Complete the following steps (adhere to the steps that pertain to your device's operating system):
Windows devices:
2.1 Open Command Prompt or PowerShell as Admin.
2.2 Right-click the Start button and select Command Prompt (Admin) or PowerShell (Admin).
2.3 Set the new hostname:
`Rename-Computer`
2.4 Replace NewHostname with your desired hostname.
2.5 Restart your device for the change to take effect:
`shutdown /r /t 0`
Linux devices:
2.1 Use the hostnamectl command.
2.2 Replace the current hostname with the new one.
2.3 Reboot the system to apply the changes:
`sudo reboot`
Mac devices:
2.1 Open Terminal.
2.2 Set the new hostname:
sudo scutil --set HostName NewHostname
sudo scutil --set LocalHostName NewHostname
sudo scutil --set ComputerName NewHostname
2.3 Verify the change:
hostname
2.4 Optional Reboot: Most of the time, rebooting is unnecessary, but you can restart if you experience issues:
sudo reboot
Step 3:
Restart and re-register the Cloud Secure Edge desktop app, and the updated hostname should be correctly reflected in the desktop app and the Command Center.
Limitation:
The certificate is imported with admin privileges, allowing it to be added to the Keychain. In the following installation step, the user is prompted to trust the previously imported certificates. For both importing and trusting, we use macOS-provided APIs; due to a bug in these APIs, even if the user cancels the trust prompt, the certificate is still marked as trusted in the Keychain. This issue is specific to macOS Sequoia, and there is currently no fix available from SonicWall CSE app side.
Our command tool can detect and log when a certificate is not trusted, but due to this macOS behaviour, the certificate may still appear as trusted in the Keychain.
Cloud Secure Edge Component(s):
Workaround:
No workaround.
Limitation:
When more than one United States Point of Presence is enabled for a device population, automatic PoP selection consistently favors other US PoPs over Council Bluffs, including for users physically closest to it. The network location currently used to measure latency for this PoP differs from its physical location, so the PoP appears more distant than it is during selection.
Cloud Secure Edge Component(s):
Workaround:
Admins can select only Council Bluffs in North America.
Limitation: End users who registered their mobile devices with CSE using Active Directory (LDAP) authentication were unable to re-authenticate once their initial session (typically 24 hours long) expired. End users received an error message that read: Bad Request Connector ID does not match a valid Connector. This affected orgs that had configured end user authentication for AD.
Cloud Secure Edge Component(s):
Limitation: When an iOS device was connected to the Service Tunnel and the user roamed from an IPv6-only network to an IPv4 network, traffic through the tunnel failed to recover automatically.
Cloud Secure Edge Component(s):
Limitation: When an iOS device was connected to a Service Tunnel over cellular and then switched to a Wi-Fi network, DNS resolution stopped working through the tunnel and the CSE mobile app displayed a blank loading page. The tunnel status also became inconsistent between iOS Settings > VPN and the in-app status indicator.
Cloud Secure Edge Component(s):
Limitation: When a device did not have a serial number registered with the app, the app was unable to communicate with the Command Center. CSE now generates a device identity automatically when no serial number is present, so registration and communication no longer depend on the device's serial number.
Cloud Secure Edge Component(s):
Limitation: When end users restarted their macOS Sequoia devices, their Service Tunnels failed to reconnect when Connect on Login and the Prevent users from choosing a Service Tunnel setting were both enabled.
Cloud Secure Edge Component(s):
Limitation: The Cloud Secure Edge (CSE) app did not support Ubuntu 24.04's new architecture. During installation, the app ran a command (sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0) to remove Ubuntu's new security restriction so that the app could run.
Cloud Secure Edge Component(s):
Limitation: Internet connectivity was disrupted on Ubuntu 22.04 devices with ITP enabled when rapidly switching between blocked sites (as configured by ITP policies) and non-blocked sites. The root cause was the older systemd version packaged with Ubuntu 22.04 (bug report).
Cloud Secure Edge Component(s):
Limitation: For some admins, the AD/LDAP end user configuration setting is not visible. This happens when the associated Connector is not Reporting. If the Connector is Reporting, the AD/LDAP settings are displayed.
Cloud Secure Edge Component(s):
Workaround: Check associated Connector to ensure that it is Reporting.
Limitation: Admins whose orgs use URL Blocking may see an option to use Explicit URL Blocking in an ITP Policy configuration. This toggle is visible but non-functional.
Cloud Secure Edge Component(s):
Workaround:
No available workaround; if toggled on, the Explicit URL Blocking will not be functional.
Limitation:
macOS's new update (i.e., macOS Sequoia) will not allow installation of trusted certificates without action on behalf of the end user. This means that when end users are registered to the Cloud Secure Edge app, certs will not be installed as usual, thus blocking end user access to services and blocking ITP policy enforcement.
Workaround: If your company uses an MDM provider, this update will not be an issue, since MDM providers can install certificates on behalf of the end user.
Limitation:
When admins who have ITP enabled in their org run DNS interceptors that listens on their DNS ports, ITP doesn't initiate (i.e., the banyanwgs is unable to bind to its port and hence does not take over DNS on the device). Currently, there is no indication (in the logs or Healthcheck) that ITP isn't working, and the ITP health check erroneously reports that it is working.
Workaround:
Ensure that the service that is using port 53 is not running when you start ITP.
Verify using the following command:
sudo lsof -i -P -n | grep ":53$"