Routing Cloud Secure Edge (CSE) Traffic to Remote Sites via Site-to-Site VPN

This article describes how to configure routing to allow Cloud Secure Edge (CSE) users to access resources located at a remote site (Site B) via a Connector installed at a central site (Site A), using an existing Site-to-Site VPN tunnel.

Scenario

• Site A: Contains a SonicWall Firewall and a deployed CSE Connector.
• Site B: Contains target resources/servers, connected to Site A via a Site-to-Site VPN.
• Goal: Remote users connected to CSE need to access resources at Site B.

Best Practice Recommendation

If you have administrative control over the firewall at Site B, the recommended solution is to deploy a Connector directly at Site B. You can then add this connector to the Service Tunnel. This eliminates the need to route traffic over the VPN and provides better performance and redundancy.

If deploying a connector at Site B is not possible, proceed with the routing configuration below.

Configuration Steps

To route traffic successfully from the CSE Connector at Site A to the resources at Site B, two requirements must be met:

1. Connector Routes: The Connector must know where to send the traffic.
2. Return Traffic Routing: Site B must know how to return traffic to the CSE infrastructure.

Step 1: Configure Connector Routes

Ensure that the IP subnets for Site B are included in the Connector configuration at Site A. This tells the Connector to tunnel traffic destined for Site B through the Service Tunnel.

Step 2: Configure Return Traffic

The most common point of failure is that Site B receives the traffic but drops the response because it does not recognize the source IP (the CSE Access Tier IPs). You must implement one of the following three options to ensure traffic can return correctly.

Option A: Source NAT (SNAT) - Recommended for ease of use

This method "hides" the CSE source IP addresses behind a local IP address at Site A (such as the firewall's LAN/X0 interface). Site B already knows how to route back to Site A's LAN, so no changes are required at Site B.

• Configuration: Create a NAT rule on the Site A Firewall:
• Original Source: CSE_Access_Tier_AIPs (The Object Group containing CSE source IPs)
• Translated Source: X0 IP (Or the Interface IP of the tunnel endpoint)
• Destination: Site B Network Subnets
• Original Service: Any
• Translated Service: Original

Option B: Policy-Based VPN Update

If you use a standard Policy-Based VPN (where "Local" and "Remote" networks are defined in the VPN policy itself), you must explicitly allow the CSE IPs across the tunnel.

• At Site A: Update the VPN Local Network configuration to include the CSE_Access_Tier_AIPs object group.
• At Site B: Update the VPN Remote Network configuration to include the CSE_Access_Tier_AIPs object group.

Option C: Route-Based VPN (VTI) Update

If you use a Route-Based VPN (Tunnel Interface), traffic is controlled by the routing table rather than policy definitions. Site B needs a static route to send traffic destined for CSE back through the tunnel.

• Action: Add a static route on the Site B Firewall/Router.
• Destination: CSE_Access_Tier_AIPs (you can find this on the Site A firewall or in the CSE console under Settings -> Configuration -> Service Tunnel -> access_tier_satellite and access_tier_gre_tunnel if you have Public IP support enabled).
• Interface / Next Hop: Select the VPN Tunnel Interface connected to Site A.

Why this is required: Without this route, Site B will likely route the return traffic for CSE IPs out to its default gateway (Internet), causing the connection to fail because of asymmetric routing.

Important Terminology Note

• Access Tiers / Points of Presence (PoPs): In some documentation and UI versions, the CSE Global Points of Presence are referred to as "Access Tiers." When configuring rules involving CSE_Access_Tier_AIPs, you are referencing the public IPs of the cloud infrastructure.