Known Issues
This section lists the current known limitations (and available workarounds) of SonicWall Cloud Secure Edge (formerly Banyan Security)
- Updated on Oct 14, 2024
- On macOS Sequoia, the desktop app trusts the certificate when the user cancels the certificate prompt
- Service Tunnel fails to reconnect after macOS Sequoia restart when Connect on Login is enabled
- Ubuntu 24.04 uses a new architecture that prevents the Cloud Secure Edge app from running
- Intermittent network disconnection on Ubuntu 22.04 when ITP is enabled
- Fixed Issues
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$"
Can’t find what you’re looking for?
We’re happy to help. Contact our team.