• DNS Resolution
• Network-layer Steering
• Application-layer Proxying
• Application Authentication
• Other Scenarios
  • 1. Clientless access
  • 2. Site-based enforcement
  • 3. Co-existing with traditional L3 VPN
  • 4. Co-existing with on-premise Web Proxy

Unlike traditional networking tools that require complex and often incompatible configurations (such as VPN profiles, segmentation rules, PAC files, etc. to route and inspect traffic), SonicWall only requires administrators to specify services and policies for their workforce. SonicWall then automatically selects the appropriate mechanism to securely connect a user to the resource they need to access and to enforce the requisite security policies.

Routing Framework

SonicWall Cloud Secure Edge routing framework is applied at different layers of the networking stack:

1. DNS Resolution - how a domain is resolved on the device
2. Network-layer Steering - whether a packet is steered over a tunnel or the internet
3. Application-layer Proxying - whether a request should terminate TLS and be proxied or not
4. Application Authentication - how the resource identifies the user accessing it

When Internet Threat Protection (ITP) is enabled, Cloud Secure Edge automatically updates the routing logic on a device to secure access to internet resources as well as private resources.

DNS Resolution

DNS determines how a domain name is resolved to an IP address, and is configured as follows:

1. Private domains are resolved at internal DNS servers, typically over a Service Tunnel
2. Published services use Service Domain Names that resolve via public DNS servers to your organization’s Edge
3. If ITP is enabled, domains are inspected via the DNS filtering capability and threats are blocked
4. If ITP is not enabled, domains are resolved at the DNS server specified by the device’s network

Additional reading:

• DNS and routing when securing private resources such as internal websites and infrastructure servers.
• DNS and routing when securing networks using Service Tunnel.

Network-layer Steering

Cloud Secure Edge makes a decision about whether to route a packet over a tunnel or directly to the internet:

1. Private network traffic flows over a Service Tunnel
2. Specified tunnel domains & CIDRs also flow over a Service Tunnel
3. Published services utilize TLS encryption and are routed over the public internet to your organization’s Edge
4. If ITP is enabled, URLs are inspected on device via URL filtering; threats are blocked and risky URLs are forwarded to the Edge for further inspection
5. All other traffic flows over the public internet to its destination

Additional reading:

• Routing public domains over a tunnel for IP whitelisting
• Security for internet traffic that is always-on but not always-inline

Application-layer Proxying

The Edge comprises of identity-aware reverse proxies as well as a TLS-inspection forward proxies that enforce least-privilege-access and data-loss policies.

1. Published services are proxied through the Edge; the Edge terminates TLS and forwards requests to the backend
2. If ITP is enabled, risky URLs are inspected at the Edge; the Edge intercepts TLS and blocks threats
3. If Data Loss Prevention (DLP) is enabled, specific domains are inspected at the Edge; the Edge intercepts TLS and applies DLP policies
4. If application-layer access policies are specified, L7 requests and responses are examined and policies are enforced

Additional reading:

• Applying API-level policies for hosted websites
• Defining Data Loss Prevention (DLP) policies for sensitive applications

Application Authentication

SonicWall Cloud Secure Edge issues short-lived cryptographic credentials - SAML and OIDC tokens, X.509 and SSH certificates - that can be used for application authentication.

1. SaaS applications can use Cloud Secure Edge’s IDP federation to authenticate users
2. Infrastructure resources (SSH server, K8s API) can use Cloud Secure Edge’s tokens and certificates for authentication and authorization
3. Based on the policies specified, Cloud Secure Edge can enforce user- and device-based controls

Additional reading:

• Protect SaaS applications with IDP Federation where CSE enforces device trust policies
• Use SSH certificate authentication to manage end user access to Linux servers

Other Scenarios

A few other scenarios that SonicWall supports that are not explicitly called out in the framework above are noted here:

1. Clientless access

Users without a CSE client cannot set up Service Tunnel-based connectivity. In this scenario, you can use CSE’s published services capability. Published services resolve via public DNS servers and are proxied through the Edge, which terminates TLS using trusted Let’s Encrypt certificates and enforces application-layer policies.

2. Site-based enforcement

CSE can be used to enforce policies at a site level in addition to enforcing policies at the user & device level. A site is a single network location, with a fixed IP address, associated with the Connector component. The Connector forwards traffic to the Global Edge Network where site-based policies are enforced.

3. Co-existing with traditional L3 VPN

CSE can operate seamlessly atop an existing L3 VPN. Typically, traffic to published services flows over the public internet. However, you can configure private or public DNS so traffic will flow over your L3 VPN tunnel instead of the public internet.

4. Co-existing with on-premise Web Proxy

CSE can operate seamlessly in secure networks that require all web traffic to be inspected by a web proxy. The desktop app and Access Tier both respect the OS’s http_connect proxy setting, and so can communicate with the Cloud Command Center.

What’s next

Read more about how zero-trust policies work in SonicWall Cloud Secure Edge.