Extend Perimeter Protection of SonicWall Firewalls
How-to guideUse Cloud Secure Edge to extend the protections of your SonicWall firewalls to users on any network
- Last validated: Oct 21, 2026
- 8 minutes to read
- Overview
- Moving from a SonicWall firewall
- Block known threats
- Enforce acceptable use
- Block risky URLs
- Inspect encrypted traffic
- Stop malicious downloads
- Restrict by geography
- Control applications and AI use
- Use CSE alongside your SonicWall firewall
- Roll out and verify
- FAQs
- Do users need to be signed in to SPA or connected to a Service Tunnel for ITP to apply?
- Do my policies apply when users are off the corporate network?
- Can users reach the internet directly, without backhauling traffic through the office?
- Can I keep using my SonicWall firewall?
- Can CSE inspect encrypted HTTPS traffic?
- Does CSE use SonicWall Capture ATP to analyze downloads?
- Can I stop users from turning off protection?
Overview
SonicWall firewalls apply web filtering, threat prevention, encrypted traffic inspection, and application control at the edge of the corporate network. Those controls protect users while their traffic passes through the firewall.
Secure Internet Access (SIA) in SonicWall Cloud Secure Edge (CSE) extends those protections to users wherever they work, whether that is the office, a home network, or public Wi-Fi. SIA applies them through Internet Threat Protection (ITP) policies, which provide the CSE Secure Web Gateway (SWG) and Firewall as a Service (FWaaS) capabilities. ITP enforces each policy on the user’s device and in the CSE SWG, which runs in SIA points of presence (PoPs) around the world.
Note: ITP does not depend on Secure Private Access (SPA). Users do not need to be signed in to SPA or connected to a Service Tunnel for their ITP policy to apply.
Each section on this page covers one outcome: what to turn on, the license it needs, and where to find the full steps. For the short sequence that protects your organization with ITP, see Block Malicious Internet Content.
How it works
- Enforced on the device and in the SWG. You define what to allow or block in an ITP policy, and ITP evaluates each device’s internet traffic in three stages. DNS-layer security evaluates each domain in the CSE SWG. URL filtering runs primarily on the device. Payload inspection runs in the CSE SWG when TLS decryption is on. See Securing Internet Traffic and ITP Architecture.
- Always-on but not always-inline. Without TLS decryption, the device asks ITP whether to allow each domain and then connects to the site directly, so the traffic itself does not pass through CSE. With TLS decryption on, traffic that matches the policy passes through the SWG in the CSE data center nearest to the user, where it is inspected.
- No backhaul. Policies follow users on any network, so you do not need to route their internet traffic back to an office or a central data center to apply your controls.
- Decisions use identity. ITP policies are assigned through roles, so a user’s identity determines which policy their devices receive.
Moving from a SonicWall firewall
If you already configure these controls on a SonicWall firewall, use the following table to find the CSE equivalent of each feature.
| SonicWall firewall feature | CSE equivalent | Where you configure it | License |
|---|---|---|---|
| Content Filtering Service (CFS) | Category Blocking, and Domain and URL Blocking | ITP policy, Blocking step | SIA for categories and domain entries, SIA Advanced for URL entries |
| CFS exclusions and allow lists | Domain and URL Bypass | ITP policy, Bypass step | SIA for domain entries, SIA Advanced for URL entries |
| Reputation-based blocking and Botnet Filter | Auto-enabled threat protection categories, and Risk-based URL Blocking | ITP policy, Blocking step | SIA for threat protection, SIA Advanced for Risk-based URL Blocking |
| Capture Advanced Threat Protection (Capture ATP) | File Analysis in Malware Download Protection, which uses Capture ATP static analysis and sandboxing with SonicWall’s patented Real-Time Deep Memory Inspection (RTDMI), and holds each download until a verdict is returned | ITP policy, Blocking step | SIA Advanced |
| Deep Packet Inspection of SSL (DPI-SSL) | TLS decryption | ITP policy, Assignment step, Enable Advanced Configurations | SIA Advanced for the features that depend on it |
| Geo-IP Filter | Geo-Blocking | ITP policy, Blocking step | SIA Advanced |
| App Control | Application Blocking and Application Bypass | ITP policy, Blocking and Bypass steps | SIA |
For what each license tier includes, see Cloud Secure Edge (CSE) Licenses.
Block known threats
Every ITP policy blocks a set of common threat categories automatically. You do not configure them, and they stay on for every policy:
- Bots / Cryptomining
- Dangerous Configuration / History
- Dangerous 3rd Party Infrastructure
- Dangerous Nameserver
- Malicious SSL Cert
- Malware & Ransomware
- Malware C2
- Phishing
- Risky DNS Transactions
- Spam / Ad Fraud / Spyware
- Other Known Bad (Community Intelligence)
- New Domains, which are domains created within the last 30 days
What to turn on: Create an ITP policy, and attach the roles of the users you want to protect. The threat categories apply as soon as the policy reaches their devices.
License: SIA.
Full steps: Create an ITP Policy.
Enforce acceptable use
Block the content that your acceptable use policy does not permit, and allow the exceptions that your business needs:
- Category Blocking blocks whole content categories, such as Gambling or Adult Content.
- Domain Blocking blocks the domains you enter. With TLS decryption on, this setting becomes Domain and URL Blocking and also blocks the URLs you enter, such as
example.com/downloads. - Domain Bypass exempts the domains you enter from every ITP rule. With TLS decryption on, this setting becomes Domain and URL Bypass and also accepts URLs. Bypasses are evaluated before any block rule. Add each of your internal domains here, so that users can reach your internal resources.
When ITP blocks a site, the user sees a block page with the message you enter in the policy. Include how to reach your help desk in that message.
Warning: Bypassed traffic skips every ITP rule, including the auto-enabled threat protection categories, and it does not appear in logging. Keep each bypass entry as narrow as you can.
What to turn on: Category Blocking and Domain Blocking in the policy’s Blocking step, and Domain Bypass in its Bypass step.
License: SIA for Category Blocking and for domain entries. URL entries in Domain and URL Blocking and Domain and URL Bypass require SIA Advanced.
Full steps: Step 2: Blocking and Step 3: Bypass. For the order in which ITP applies these rules, see How ITP rules are processed.
Block risky URLs
A trusted domain can still host a malicious URL. Risk-based URL Blocking checks each full URL for threats and blocks the risky ones. It inspects the URLs that the policy has not already blocked through Category Blocking, Domain Blocking, Application Blocking, or threat protection.
What to turn on: Risk-based URL Blocking in the policy’s Blocking step. The toggle appears when TLS decryption is on.
License: SIA Advanced. Also requires Windows or macOS devices with desktop app 3.26.0 or later.
Full steps: Enabling Risk-based URL Filtering.
Inspect encrypted traffic
Most internet traffic is encrypted with Transport Layer Security (TLS). Without decryption, ITP sees only the domain that a user connects to. With TLS decryption on, the CSE SWG decrypts HTTPS connections that match the policy, inspects them, and re-encrypts them with a certificate from the CSE certificate authority (CA). ITP then sees each full URL, the files users download, and the account a user signs in with, and the Internet Access Logs record full URLs.
TLS decryption is what enables URL entries in Domain and URL Blocking and Domain and URL Bypass, Risk-based URL Blocking, File Analysis, and Require Approved Accounts for AI Apps.
The CSE desktop app installs the CSE CA certificates in the operating system certificate store, so browsers and most applications keep working. On Macs, deploy the SWG CA certificates with your MDM system before you turn on TLS decryption, so that users are not asked to approve them. See Distributing the SWG CA certificates to macOS devices. SonicWall also maintains Global TLS Decryption Exclusions for every org. Before you turn on TLS decryption for a group of users, identify applications that pin certificates and services that allowlist your IP addresses, and turn it on for a pilot group first.
What to turn on: Enable Advanced Configurations in the policy’s Assignment step. This toggle turns on TLS decryption for the policy.
License: URL entries in Domain and URL Blocking and Domain and URL Bypass, Risk-based URL Blocking, File Analysis, and Require Approved Accounts for AI Apps, which depend on TLS decryption, require SIA Advanced.
Full steps: TLS Decryption, and Turn on TLS decryption in the rollout guide. For applications that pin certificates, see SWG CA Certificates for Certificate-Pinned Apps.
Stop malicious downloads
File Analysis, part of Malware Download Protection, inspects the files that users download through the SWG before the files reach the device. It uses SonicWall Capture Advanced Threat Protection (Capture ATP) static analysis and, for files that need deeper analysis, sandboxing with SonicWall’s patented Real-Time Deep Memory Inspection (RTDMI) technology. Each inspected download is held until a verdict is returned. Malicious files are blocked, the user is notified, and CSE records a Malware event.
What to turn on: File Analysis in the policy’s Blocking step. The toggle appears when TLS decryption is on.
License: SIA Advanced. Also requires Windows or macOS devices with desktop app 4.2.0 or later.
Full steps: Malware Download Protection.
Restrict by geography
Geo-Blocking blocks the IP ranges associated with the countries you select.
What to turn on: Geo-Blocking in the policy’s Blocking step. Select + Select countries, and then select the countries to block.
License: SIA Advanced.
Full steps: Step 2: Blocking.
Control applications and AI use
Control applications by name rather than by domain, and keep AI use on the accounts your organization manages:
- Application Blocking blocks the applications you select from the CSE catalog of more than 6,000 categorized applications, plus any custom applications you create. To block a whole category, such as generative AI, filter App Discovery by that category, and then select each application.
- Application Bypass exempts the applications you select from ITP.
- App Discovery lists the applications your users reach, including the ones IT has not approved, and tags new applications and AI applications. From an application’s page, you can add it to an ITP policy to block or allow it.
- Require Approved Accounts for AI Apps blocks prompts sent to supported AI apps from personal, free, or anonymous accounts, so users work in the accounts your organization controls. This setting is a preview feature.
For an end-to-end workflow that combines these settings, see Shadow IT & AI Governance.
What to turn on: Application Blocking in the policy’s Blocking step, and Application Bypass in its Bypass step. For AI accounts, Require Approved Accounts for AI Apps in the Blocking step, which appears when TLS decryption is on.
License: SIA for Application Blocking, Application Bypass, and App Discovery. SIA Advanced for Require Approved Accounts for AI Apps, which also requires desktop app 4.6.0 or later.
Full steps: Step 2: Blocking, App Discovery, and Require Approved Accounts for AI Apps.
Use CSE alongside your SonicWall firewall
You do not need to replace your firewall to use CSE. A common design keeps the SonicWall firewall protecting the office network and uses CSE to protect users wherever they work:
- The same ITP policy in and out of the office. ITP policies apply on the device, so users receive the same ITP policy whether they work in the office or away from it.
- Firewall TLS inspection. If the firewall runs DPI-SSL, exclude
*.swg.banyanops.comfrom TLS inspection on the firewall, so that the firewall does not decrypt the connection between the desktop app and the CSE SWG. See Firewalls with their own TLS inspection. - Outbound DNS. The desktop app sends DNS traffic to CSE over DNS over TLS (DoT). If the firewall restricts outbound DNS, allow this traffic. See Network and DNS.
Roll out and verify
Roll out ITP in stages: one pilot user first, then groups of users in waves, then an organization baseline policy. Turn on TLS decryption as a second step, for the pilot user first, after the basic policy works. Roll Out ITP in Your Org has the full sequence.
1. Assign users to the policy. ITP policies apply to users through the roles you attach.
- If SCIM is enabled in your org, attach the roles of your users to the ITP policy directly.
- If SCIM is not enabled, ask your users to sign in to the CSE app and register their devices, and then attach their roles to the policy.
2. Exclude the users or devices that should not receive an ITP policy, by attaching their roles to the Excluded Devices policy. It always takes precedence over every other ITP policy, and it includes the Mobile Devices role. See Exclude Users from ITP Policies.
3. Verify the policy:
- Use Lookup Domain to see the content categories and threat classification of a domain, and whether your policy blocks or allows it.
- Review the Internet Access events in Events, which include Threat, Compliance, Malware, and ITPStatus events. The Command Center retains events for 14 days. To keep them longer, export them.
- Download the Access Logs, which record the requests that ITP blocks and allows, and which remain available for up to 12 months. With TLS decryption on, they record the full URL of each request.
4. Optional: To stop users from turning ITP off on their own, turn on Require a passcode to disable ITP.
FAQs
Do users need to be signed in to SPA or connected to a Service Tunnel for ITP to apply?
No. ITP is enforced independently of Secure Private Access (SPA). The ITP policy assigned through a user’s roles applies to their registered devices whether or not they are signed in to SPA or connected to a Service Tunnel.
Do my policies apply when users are off the corporate network?
Yes. ITP policies are enforced on the device and in the CSE SWG, so they apply on any network a user connects from, including home networks and public Wi-Fi. Users do not need to connect to a VPN or reach your office for their policy to apply.
Can users reach the internet directly, without backhauling traffic through the office?
Yes. Without TLS decryption, the device connects to allowed sites directly after ITP evaluates the domain. With TLS decryption on, inspected traffic passes through the SWG in the CSE data center nearest to the user. In both cases, internet traffic does not need to be routed through your office or data center.
Can I keep using my SonicWall firewall?
Yes. Your firewall can continue to protect the office network while CSE protects users wherever they work. See Use CSE alongside your SonicWall firewall.
Can CSE inspect encrypted HTTPS traffic?
Yes. Turn on TLS decryption in the ITP policy with Enable Advanced Configurations. CSE then inspects full URLs and downloaded files in HTTPS traffic that matches the policy. See Inspect encrypted traffic.
Does CSE use SonicWall Capture ATP to analyze downloads?
Yes. File Analysis in Malware Download Protection uses SonicWall Capture Advanced Threat Protection (Capture ATP) static analysis and sandboxing with SonicWall’s patented Real-Time Deep Memory Inspection (RTDMI) technology. Each inspected download is held until a verdict is returned. See Malware Download Protection.
Can I stop users from turning off protection?
Yes. Turn on Require a passcode to disable ITP, so that a user needs a one-time passcode from an admin before they can turn ITP off. ITP also turns back on automatically 1 hour after it is turned off. See Require a passcode to disable ITP.
What’s next
- Manage Internet Threat Protection (ITP) Policies covers every setting in an ITP policy.
- Roll Out ITP in Your Org takes a policy from one pilot user to your whole organization.
- Block Malicious Internet Content gives the short sequence that protects your organization with ITP.