Before you begin
- A Atlas AVD plan. The Integrations hub is not available on Community
- The Administrator role in Atlas to connect, configure or disconnect a connector. Integrations appears under Administration only for administrators
- A tenant selected in the tenant picker. Credentials are stored encrypted per tenant, so each tenant you manage connects its own account
- For a Network Security Manager connection: firewalls managed in SonicWall Network Security Manager SaaS (US or Europe), and a MySonicWall API key with MySonicWall API access enabled (MSSP partners have it by default)
- For a direct SonicOS connection: one firewall running SonicOS 7, reachable on a public https address with a publicly trusted certificate, and a read-only administrator for Atlas
- To sync into Vault: a Vault admin and at least one asset template (the Network Device template is a good fit)
What you can do
- Document every SonicWall firewall, HA standby and SonicWave access point as an Atlas Vault asset, with no manual data entry.
- Connect once with a MySonicWall API key to cover every customer tenant you manage in NSM, or connect a single firewall that is not in NSM directly.
- Map each MySonicWall tenant, or the directly connected firewall, to the customer company it belongs to.
- Keep the documentation current: every hour Atlas adds new devices, updates changed details and archives devices NSM no longer reports.
- See what changed and when: firmware, management IP, MAC address, name, HA role and access point placement changes, each with the previous value kept.
- Ask Atlas Advisor about documented equipment, for example "Which SonicWall firmware versions do we have?"
Choose a connection type
- Network Security Manager: every firewall in each MySonicWall tenant you manage in NSM, read through NSM. Nothing has to be opened on the firewalls. Use this whenever your firewalls are in NSM.
- SonicOS: one firewall that is not managed in NSM, read directly through its own SonicOS API. Each Atlas tenant connects one SonicWall source, so use this for a customer with a single firewall outside NSM.
- Both types document the same details. Follow Steps 1 to 3 for Network Security Manager, or the SonicOS section below for a direct connection.
Step 1: Create a MySonicWall API key
- Sign in to MySonicWall, go to My Workspace → User Groups → User List and click Generate API Key. Copy the key when it is shown; it is shown only once and is valid for a year by default.
- The key acts with the permissions of the MySonicWall user it belongs to, and can reach every tenant that user can. Create it for a user whose user group only covers the tenants Atlas should document.
- MSSP partners have MySonicWall API access by default. If yours is not enabled, ask SonicWall to turn on the MySonicWall API token permission for that user.
- Note which Network Security Manager region you sign in to: nsm-uswest.sonicwall.com (US) or nsm-eucentral.sonicwall.com (Europe).
Step 2: Connect in Atlas
Once connected, the card shows Manage, which opens Atlas Vault → Assets, and Disconnect. The key is stored encrypted and is never shown again. It is only ever sent to MySonicWall; Atlas opens a short-lived Network Security Manager session for each sync and never stores it.
- Select the tenant in the tenant picker.
- Go to Administration → Integrations and click Connect on the SonicWall card.
- Connection type: Network Security Manager.
- Choose your Network Security Manager region.
- Paste the MySonicWall API key.
- Click Connect. Atlas lists your MySonicWall tenants with the key before saving anything; if it is rejected, nothing is stored.
Step 3: Map each tenant to a company
Add one sync per tenant. Each tenant can be mapped only once in an Atlas tenant, so its equipment never ends up under two companies.
- Open Atlas Vault → Assets → RMM & PSA sync and click Add sync.
- Source: SonicWall.
- Device type: pick a tenant. Only MySonicWall tenants with Network Security Manager are listed.
- Template: pick Network Device. Atlas fills in the field mappings for you: Name, Type, Manufacturer, Model, Serial Number, Management IP, MAC Address and Firmware Version. You can change or add any mapping.
- Company: the customer this tenant belongs to.
- Leave Sync automatically every hour on, click Save Changes, then click Run now to document it straight away.
Connect one firewall directly through SonicOS
The password is stored encrypted and is never shown again. Firmware 7.3.2 and later can also issue bearer tokens for API sessions; Atlas uses one when the firewall offers it. If you later connect a different firewall with new credentials, the existing sync returns nothing for the old firewall: add a sync for the new one.
- On the firewall, go to Device → Settings → Administration → Audit/SonicOS API, turn on Enable SonicOS API and RFC-7616 HTTP Digest Access authentication, and save.
- Go to Device → Users → Local Users & Groups and add a local user for Atlas that is a member of the SonicWALL Read-Only Admins group. Use a strong password.
- Make sure Atlas can reach the firewall's management interface on a public https address (for example https://fw.example.com:4443) that presents a publicly trusted certificate. Private and internal addresses, and self-signed certificates, are refused.
- In Atlas, select the tenant, go to Administration → Integrations and click Connect on the SonicWall card.
- Connection type: SonicOS. Enter the firewall address, the administrator's username and password, and click Connect. Atlas signs in, reads the firewall's model and serial number and signs out before saving anything; if the sign-in is rejected, nothing is stored.
- Open Atlas Vault → Assets → RMM & PSA sync, click Add sync, choose Source: SonicWall and pick the firewall as the Device type, then a template and the customer company, as in Step 3.
A SonicOS API sign-in is an administrator session. Use an account created only for Atlas that nobody signs in to the web console with: if someone is signed in with the same account, Atlas signing in can end their session. Atlas signs in with HTTP Digest, so the password itself is never sent, and it signs out at the end of every sync.
What gets documented
- Identity: name, manufacturer (SonicWall), model, product code and serial number, and an access point's MAC address.
- Type: Firewall or Access Point, and the product line (TZ, NSa, NSsp or NSv Series, SonicWave or SonicPoint).
- Network: the firewall's management address in NSM (not available on a direct SonicOS connection), and an access point's IP address, port and zone.
- Software: SonicOS firmware version and ROM version.
- Operational: online or offline, and the HA role (primary or secondary) with the partner unit's serial number.
- Placement: the firewall an access point is managed by, and the MySonicWall tenant (Network Security Manager connections).
Firewalls are matched by serial number and access points by MAC address, so renaming a device or changing its IP updates the same asset instead of creating a new one. Atlas never reads or keeps firewall admin passwords, authentication codes, registration codes or licence keys. Connected clients and firewall policy are not documented.
Your own documentation is kept
Atlas only fills the fields you map. Notes, attachments, custom fields and anything else you add in Vault are yours and are never touched. If you edit a mapped field by hand, Atlas keeps your value; if SonicWall later reports something different, the field is flagged under Drift to review so you can choose which to keep. A device SonicWall stops reporting is archived, not deleted, and comes back automatically if it returns. Atlas archives a device only after a complete read, so an offline firewall, an outage or a rejected key never empties your documentation.
Change history
Open an asset's ⋯ menu and choose History to see what changed: when the device was first documented, a new name, model, management IP, MAC address, firmware, HA role, managing firewall or zone (each with the previous and new value), when it was no longer reported, and when it came back. Routine online and offline changes are not recorded. The same entries appear on the Operations Timeline.
Ask Atlas Advisor
Atlas Advisor answers questions from the documented assets, read-only and limited to what you can see in Vault, with or without an AI provider. For example: "list our SonicWall firewalls", "Which SonicWall firmware versions do we have?", "Which SonicWave access points are offline?" or "Is SonicWall connected?".
What the integration does not do
- It is read-only. It never changes configuration, deploys templates, fails over an HA pair or upgrades firmware.
- It does not document connected clients or firewall policy.
- It reads firewalls through Network Security Manager SaaS, or one firewall directly through SonicOS 7. NSM on-premises and firewalls running SonicOS 6 are not read.
- It syncs every hour or when you click Run now; the interval cannot be changed.
- It connects one SonicWall source per Atlas tenant: one MySonicWall API key, or one directly connected firewall. Credentials cannot be edited in place: disconnect and connect again with the new key or password.
GCC High tenants
On a tenant or deployment in Azure Government (GCC High), calls to SonicWall are blocked by default, because they can carry VM, host-pool and tenant names to a service outside the Government boundary. Connect fails with an Azure Government (GCC High) egress boundary message and nothing is stored, and pages that read from SonicWall stay empty. The operator who runs your Atlas deployment can approve SonicWall as a destination that is allowed to receive that data; once approved, the connector works normally. Running in Azure Government does not by itself make a third-party integration GCC High or CMMC compliant.
Disconnecting
Click Disconnect on the card and confirm. Atlas deletes its stored copy of the API key or administrator password and pauses every Atlas Vault sync from SonicWall. The documented assets and their history stay in Vault; turn the syncs back on after you reconnect. Nothing changes in MySonicWall, Network Security Manager or on the firewall. Delete the API key in MySonicWall, or the Atlas administrator on the firewall, if you no longer need it.
Troubleshooting
- The connection test fails with 401: the key is wrong, expired or revoked, or MySonicWall API access is not enabled for its user.
- A tenant is missing from the Device type list: it has no Network Security Manager, or the key's user cannot see it.
- A firewall's access points are missing: the firewall was offline or not reachable through NSM during the sync. Its existing access points are kept and refresh once it is back.
- A direct SonicOS connection fails with 401: the username or password is wrong, Digest authentication is not enabled under Audit/SonicOS API, or another session is using the same administrator account.
- A direct SonicOS connection is refused before it reaches the firewall: the address is private or internal, is not https, or its certificate is not publicly trusted.
- A direct SonicOS connection reports a response that is not JSON: the SonicOS API is not enabled on the firewall.
- SonicWall is temporarily rate limiting requests: scheduled syncs wait and retry on their own; try again in a few minutes.
- A sync reports the integration is not configured: SonicWall was disconnected. Connect it again, then turn the sync back on.