Full Tunnel in SonicWall Cloud Secure Edge (CSE)

Overview

When migrating from traditional VPNs to a modern Zero Trust Network Access (ZTNA) architecture like SonicWall Cloud Secure Edge (CSE), administrators frequently ask how to configure a "Full Tunnel." Historically, full tunnels were used to backhaul all user traffic to a corporate firewall to enforce security, filter web traffic, or control application access.

In a Zero Trust architecture, however, routing all traffic through a centralized gateway can introduce latency and impact network performance. Often, the request for a full tunnel stems from specific functional requirements that can be addressed more efficiently with targeted routing. This Knowledge Base article breaks down these common scenarios, explains the recommended CSE architecture for each, and provides guidance for traditional full tunnel deployments when required by strict compliance mandates.

Scenario 1: IP Whitelisting for SaaS Applications

Common Requirement: Administrators route all user traffic through a full tunnel so that requests to SaaS applications (like Salesforce or Microsoft 365) appear to originate from a single, trusted corporate IP address.

The CSE Approach: CSE can achieve SaaS IP restrictions without requiring a full tunnel. You can secure and route specific public traffic using Service Tunnels in a split-tunnel configuration.

• Egress via Global Edge: You can route specific SaaS domains or IP ranges through SonicWall’s Global Edge Network by adding them to a Service Tunnel’s "Public Include List." Traffic egresses from SonicWall's Global Edge PoPs, and you whitelist those specific PoP IP addresses in your SaaS app.

• Egress via Corporate IP: Alternatively, you can route that specific SaaS traffic back through your on-premises CSE Connector, Private Edge, or Firewall. The traffic egresses from your local gateway, allowing you to utilize your existing SaaS IP whitelists.

Further Reading: IP Whitelisting Scenarios for SaaS Applications

Scenario 2: Reaching Destinations Behind an Existing Site-to-Site (S2S) VPN

Common Requirement: A full tunnel is utilized so that remote workers can connect to the main office and subsequently traverse a Site-to-Site IPsec VPN to reach resources hosted at a partner site or secondary branch.

The CSE Approach: You can bridge CSE access with your existing Site-to-Site infrastructure using a targeted split-tunnel profile. By configuring a manual NAT policy on your local firewall (acting as the CSE Connector), you can translate the internal CSE Access Tier IPs to a designated intermediate IP. This allows traffic to route cleanly over the existing S2S tunnel to the remote subnet.

Further Reading: How to reach a destination behind an existing Site-to-Site (S2S) VPN from a Banyan user connected via Cloud Secure Edge (CSE)

Scenario 3: Protecting End-User Web Browsing

Common Requirement: Organizations force all internet-bound traffic through their on-premises firewall to apply content filtering, block malicious domains, and enforce acceptable use policies.

The CSE Approach: Protecting user web browsing is effectively managed using SonicWall Secure Internet Access (SIA). SIA operates seamlessly alongside CSE to provide DNS filtering, web proxy capabilities via the same client you use for private access. This secures browsing without the need to route all general internet or high-bandwidth traffic through a corporate data center.

Further Reading: Securing Internet Traffic with SonicWall Cloud Secure Edge (CSE) - SonicWall Cloud Secure Edge Documentation

Scenario 4: When Full Tunnel is Absolutely Necessary

While the architectures above cover most use cases, strict security compliance mandates may dictate that all network traffic from a device must flow through an on-premises security appliance.

SonicWall CSE supports a Full Tunnel configuration for these requirements, provided you are utilizing a Private Edge deployment (Full Tunnel is not supported on Global Edge).

Further Reading: Configuring Full Tunnel in CSE