Known Issues

This section lists the current known limitations (and available workarounds) of SonicWall Cloud Secure Edge (formerly Banyan Security)

  • Last validated: Aug 5, 2026

PoP Management is temporarily disabled

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):

  • CSE Command Center UI

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.

Domain names that resolve to multiple sets of IP addresses configured in Tunnel Policies are causing disruptions every 10 minutes

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):

  • Netagent

Workaround:

Configure the necessary IP range in your Tunnel Policy instead of using domain names.

Cloud Secure Edge desktop app displays the hostname as “unset”

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):

  • CSE desktop app
  • Command Center latest version

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.

On macOS Sequoia, the desktop app trusts the certificate when the user cancels the certificate prompt

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):

  • CSE desktop app latest version (which supports macOS Sequoia)

Workaround:

No workaround.

Clients with multiple North America PoPs enabled do not connect to the Council Bluffs PoP

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):

  • Platform

Workaround:

Admins can select only Council Bluffs in North America.

Fixed Issues

Subsequent Active Directory (LDAP) authentication attempts fail on mobile

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):

  • CSE mobile app (iOS and Android)

Traffic fails on iOS when roaming from an IPv6-only network to an IPv4 network

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):

  • CSE mobile app (iOS)

DNS resolution fails and tunnel state becomes inconsistent on iOS after switching from cellular to Wi-Fi

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):

  • CSE mobile app (iOS)

Missing Serial Number causes communication issue with Command Center

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):

  • CSE desktop app

Service Tunnel fails to reconnect after macOS Sequoia restart when Connect on Login is enabled

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):

  • CSE desktop app (macOS)

Ubuntu 24.04 uses a new architecture that prevents the Cloud Secure Edge app from running

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):

  • CSE app versions 3.18+

Intermittent network disconnection on Ubuntu 22.04 when ITP is enabled

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):

  • Ubuntu 22.04 registered devices with ITP enabled

Active Directory/LDAP end user configuration is selectively not displayed

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):

  • CSE Command Center UI

Workaround: Check associated Connector to ensure that it is Reporting.

Explicit URL Blocking is visible in the UI but isn’t available

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):

  • CSE Command Center UI

Workaround:

No available workaround; if toggled on, the Explicit URL Blocking will not be functional.

Upcoming macOS Sequoia release (coming in September 2024) will not allow installation of certificates without end user intervention

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.

ITP initiation error in orgs that have DNS interceptors listening on their DNS port as well as ITP enabled

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$"

Was this page helpful?