SonicOS 8.2.2 Frequently Asked Questions

A.  SonicOS 8.2.2 is a feature release for GEN8 firewall appliances, delivered alongside NSM 4.3. It introduces enhancements across security, virtualization, certificate management, authentication, and administration.

A.  SonicOS 8.2.2 is supported across the GEN8 hardware appliance range and the GEN8 NSv virtual firewall series. Selected features — Let's Encrypt integration and Enabling Security Services by Default — are planned for Gen7 appliances in the SonicOS 7.3.4 release.

A.  NSM 4.3 is the recommended management platform and is released alongside SonicOS 8.2.2. It provides centralized policy management, firmware upgrade orchestration, and analytics for all GEN8 hardware and NSv models running 8.2.2.

A.  SonicOS 8.2.2 is a firmware release available to appliances with a valid support entitlement. Individual security services continue to require their respective active subscriptions to operate.

A.  Full release notes, administration guides, and supporting KB articles are available on the SonicWall Knowledge Base at https://www.sonicwall.com/support/.

A.  SonicOS 8.2.2 introduces NSv Small, NSv Medium, and NSv Large, complementing the existing NSv XS. NSv Small suits SMB, branch office, and regional hub deployments (50–500 users). NSv Medium suits mid-market and distributed enterprise (50–10,000 users, up to 9.9 Gbps throughput). NSv Large suits enterprise data centers and large-scale deployments (10,000+ users, up to 14 Gbps throughput).

A.  NSv Small, Medium, and Large support VMware, Microsoft Hyper-V, KVM, and Proxmox for on-premises virtualization, as well as AWS and Microsoft Azure for cloud deployments.

A.  Classic mode is the default operational mode. Policy mode is also available and supports SAML and the CSC connector.

A.  You can enable policy mode from the advanced page in MySonicWall, or by de-registering and re-registering the firewall. A KB article documents the full procedure.

A.  As a general guide, existing NSv 200/270-class deployments map to NSv Small, NSv 400/470-class to NSv Medium, and NSv 800/870-class to NSv Large. Your SonicWall representative can help confirm the correct sizing for your environment.

A.  Four tiers are available, summarized below.

A.  Yes. Consistent with the TZ80 licensing model, the Gen8 NSv requires an active subscription to function.

A.  Gen6 NSv deployments can migrate to Gen8 NSv in global mode. Gen7 NSv deployments in policy mode can migrate to Gen8 policy mode. Migration between hardware and virtual firewalls is not supported in either direction.

A.  Yes. Direct import between NSv units in the same mode is supported. On-box migration is also supported. Note that when moving to a larger model, the target must be an upgrade — for example, NSv 400 to NSv Medium is supported, whereas NSv 400 to NSv Small is a downgrade and is not supported.

A.  Yes. NSv Small, Medium, and Large are supported in closed networks. NSv XS is not supported in closed (offline) networks.

A.  Yes. Upgrades from Gen6 or Gen7 to Gen8 currently require a reboot.

A.  Microsoft Azure supports active-passive HA. HA in AWS is planned for a future release.

A.  Yes. Firmware upgrades for NSv models and GEN8 hardware can be scheduled and performed centrally through NSM 4.3.

A.  NSv XS trials are self-service and can be activated directly from MySonicWall. Trial keys for NSv Small, Medium, and Large must be requested through your SonicWall sales representative or partner, who will help provision the appropriate model and size for your evaluation.

A.  Because NSv is a virtual platform, it does not support hardware-dependent features such as internal and external switching (SonicWall switch integration), access point/wireless management, and PoE. Administrators evaluating NSv as a hardware replacement should confirm these dependencies are met by other means, such as a separate switch or wireless controller, before migrating.

A.  8.2.2 NSv is expected to be available is expected to be available from the week of Aug 10th, subject to approvals from AWS and Azure Marketplace.

A.  On new GEN8 deployments, SonicOS 8.2.2 automatically enables Gateway Anti-Virus, Anti-Spyware, IPS, Botnet Filtering, and Geo-IP Filtering at registration. This delivers a secure-by-default posture out of the box, with no manual configuration required.

A.  No. The feature applies only to new deployments — a firewall that has been factory defaulted and freshly set up on SonicOS 8.2.2. Existing configurations are never modified during an upgrade.

A.  If a service is not licensed, traffic passes through without being scanned or blocked by that service. Once the service is licensed, scanning begins automatically. The Geo-IP database functions without a licence, while Botnet Filtering and other services require an active subscription.

A.  There is no throughput difference between a prior release running the same services and SonicOS 8.2.2 running those services. A throughput difference is only seen when comparing a firewall with no services enabled against one actively scanning traffic, which is expected behavior when security inspection is active.

A.  No. Application Control is not enabled by default in this release.

A.  Only a small, fixed set of countries where SonicWall is unable to conduct business due to regulatory mandates are on the default block list. Administrators retain full control to adjust Geo-IP policy to suit their environment. As of this release, the default block list includes Iran, Russia, and North Korea (DPRK).

A.  SonicOS 8.2.2 firewalls can obtain trusted SSL/TLS certificates automatically using the ACME protocol. The administrator generates a certificate signing request on the appliance; the firewall requests, installs, and automatically renews the certificate before it expires.

A.  No. There is no additional cost, SKU, or security subscription required. The feature is available by default.

A.  No. After the initial setup, the firewall renews the certificate automatically before expiry, with no reboot and no further administrator action required.

A.  The common name, subject distinguished name, and domain name must be publicly resolvable (a valid domain with a corresponding A record). If the domain cannot be resolved, the certificate authority cannot validate the request and issuance will not complete.

A.  The current implementation uses the HTTP-01 challenge method, which requires HTTP access on the WAN interface during validation. Support for the DNS-01 challenge method is under evaluation for a future release. The exact configuration steps are documented in the administration guide.

A.  Detailed status and failure reasons are available in both the SonicOS management interface and the Tech Support Report (TSR), including issuer information and the specific reason for a failure, such as an unresolvable domain. This allows administrators to quickly identify and correct the cause.

A.  SonicOS 8.2.2, together with Global VPN Client (GVC) 5.0.0.2008, adds TOTP-based two-factor authentication for remote-access IPsec VPN users. It supports standard authenticator applications such as Google Authenticator and Microsoft Authenticator.

A.  The workflow mirrors the existing SSL VPN two-factor setup. Enable TOTP (or one-time password via email) on the relevant local user or user group used by GVC. When the user connects, the client prompts for the code. The GVC 5.0.0.2008 client itself displays the QR code used to bind the authenticator app. SonicWall recommends disabling the virtual portal for this workflow rather than relying on it.

A.  No. It is an administrator opt-in feature. Two-factor authentication for administrator accounts is planned to be enabled by default in an upcoming release, with remote-access users to follow in subsequent releases.

A.  The current implementation supports IKEv1. IKEv2 support is being evaluated for a future release.

A.  Administrators can import a list of file hashes onto the firewall. The Gateway Anti-Virus service calculates the hash of files passing through the firewall and compares them against the imported list. If a match is found, the file is blocked and the user is notified.

A.  MD5, SHA-1, and SHA-256 hashes are supported. Up to 500,000 hashes can be imported on any appliance model. Hashes are uploaded as a text file (maximum 35 MB) with one hash value per line.

A.  Yes. When enabled, the firewall inspects traffic, extracts files, calculates their hashes, and compares them against the imported list, which introduces some throughput impact. This is expected when file inspection is active.

A.  If the same hash appears more than once across imported files, the duplicate entry is dropped automatically.

A.  No. To keep backup files compact, imported hash lists are not stored in the configuration backup or in the exported Settings file used for migration and support (TSR). Use the “export all hashes” option to save your list separately before taking a backup or generating a Settings export, and re-import it after a restore, migration, or upgrade.

A.  The system logs record that a file was blocked due to a hash match and display the first eight octets of the matching hash, allowing administrators to identify the specific hash involved.

A.  This security enhancement stores a one-way cryptographic hash of a password, with a unique random salt per password, rather than storing the password itself. This makes it infeasible to recover original passwords from a configuration backup or export.

A.  Administrator account passwords, local user passwords, guest user passwords, and the front-panel LCD PIN are stored irreversibly. Passwords the firewall must present to authenticate to external services — such as LDAP, email/SMTP, syslog, and site-to-site VPN keys — cannot be stored irreversibly and remain encrypted.

A.  No. The feature is disabled by default and must be enabled by an administrator. A per-user and per-group option is available for cases where reversible storage is required. Enabling this by default is planned for a future release.

A.  Once the feature is enabled, downgrading firmware is not supported, because an earlier firmware version cannot interpret the irreversible hashes. If a downgrade is performed, affected user passwords would need to be recreated. (Firmware downgrades are unsupported as a general policy.)

A.  With irreversible storage enabled, the scheduled periodic Credential Auditor scan does not run, as stored hashes cannot be compared against the known-compromised database. Credential Auditor still checks credentials at two points: when a user signs in, and when an administrator sets or changes a user's password (including via NSM).

A.  Yes. Stored password hashes are included in the configuration backup, so restoring onto a replacement or upgraded appliance preserves user credentials. There is no change to the end-user sign-in experience.