Known Issues

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

  • Updated on Jun 19, 2025

Missing Serial Number causes communication issue with Command Center

Limitation:

In some cases when a device does not have a serial number registered with the app, the app is not able to communicate with the Command Center.

Cloud Secure Edge Component(s):

  • CSE desktop app v3.27 (June 2025 release)

Workaround:

Option 1: Downgrade or reinstall desktop app v3.26.

Option 2: Check if /etc/banyanapp/hardware-id in mac or C:/ProgramData/Banyan/hardware-id have a populated id, e.g., below:

cat /etc/banyanapp/hardware-id {"key":"KD25xT6B8O9UdXteZM/7PmheyP0p4+b8JeF2E8Ur5b4=","id":""}%

If the id file is populated, then the file’s hardware-id can be deleted; this will resolve the issue (admin permissions are required to delete the hardware-id file).

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.

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

Limitation:

When end users restart their macOS Sequoia devices, their Service Tunnels fail to reconnect when Connect on Login and the Prevent users from choosing a Service Tunnel setting are both enabled.

Cloud Secure Edge Component(s):

  • CSE desktop app (on Ubuntu)

Workaround:

No workaround currently.

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

Limitation:

The Cloud Secure Edge (CSE) app does not currently support Ubuntu 24.04’s new architecture. During Ubuntu 24.04 installation, the CSE app runs a command (sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0) to remove Ubuntu’s new security restriction so that the app can run.

Cloud Secure Edge Component(s):

  • CSE app versions 3.18+ (CSE app versions <3.17 are not supported on Ubuntu 24.04)

Workaround:

No workaround.

Intermittent network disconnection on Ubuntu 22.04 when ITP is enabled

Limitation:

ITP relies on systemd to direct traffic or internal resources for Linux based systems, including Ubuntu 22.04. Cloud Secure Edge has identified times when internet connectivity is disrupted on Ubuntu 22.04 devices when rapidly switching between blocked sites (as configured by ITP policies) and non-blocked sites.

The root cause analysis determined that Ubuntu 22.04’s systemd is not the latest version of systemd, and this is a known issue with the version packaged with Ubuntu 22.04. A bug report has been filed here: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2030505

Cloud Secure Edge Component(s):

  • Ubuntu 22.04 registered devices with ITP enabled.

Workaround:

Use Ubuntu 24.04

Fixed Issues

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