VPN client configuration with WSSA or SEP tunnel mode

Products

Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

What are the Best Practice recommendations for VPN clients used with the WSS Agent (WSSA) or SEP client in "tunnel" mode?

Does WSSA (or SEP tunnel mode) support tunneling their traffic through a 3rd-party VPN?

Cause

WSSA (or SEP tunnel mode) does NOT support tunneling traffic through another VPN.

The Best Practice recommendation is that WSSA/SEP traffic should go out DIRECT to the Internet (and NOT route through another VPN client).

The WSSA client and SEP client (tunnel mode) leverage a tunneling protocol similar to other VPN clients.

Just as you would not route Cisco AnyConnect VPN client traffic over a Palo Alto GlobalProtect VPN client, the same principle applies for WSSA/SEP VPN tunnels.

Two problems can happen if you try to route VPN client traffic from one vendor over the VPN client from another vendor:

TCP meltdown
UDP packet fragmentation

The symptoms from both of these scenarios are that poor performance and lost packets can happen.

Due to these performance and stability implications, tunneling WSSA/SEP tunnel traffic over a 3rd-party VPN is NOT supported.

Resolution

1. Configure your VPN client for "Split tunnel" and have WSSA/SEP traffic go out DIRECT to the Internet

2. If using a "Full tunnel" VPN profile, configure WSSA/SEP to enter Passive mode when the "Full tunnel" VPN is enabled

Split Tunnel Configuration:

To avoid "tunnel in tunnel" issues, ensure that WSSA/SEP traffic is not routed through the VPN client.
The easiest way to achieve this is by configuring your VPN client in Split Tunnel mode. This ensures that internal/corporate traffic goes through the VPN, while WSSA/SEP traffic bypasses the VPN and connects directly to the internet. Additionally, configure the WSS CTC (Cloud Traffic Controller) domain and IP address to also route directly to the internet: ctc.threatpulse.com (130.211.30.2)
Failing to route CTC traffic directly to the internet will cause increased latency for WSSA/SEP.

Full Tunnel Configuration:

This option will make WSSA to go Passive. With "Full tunnel" VPN clients, your default route points to your corporate VPN server.
If you must operate your VPN client in "Full tunnel" mode (not recommended), then the best practice is to configure WSSA to go into "Passive" mode when your VPN client is active. This is done by setting a location in the Cloud SWG Portal or having Agent Traffic Manager (ATM) policy that corresponds with the location that your VPN traffic will egress out to the Internet.
In this configuration, the CTC request is routed through the "Full Tunnel" VPN client, ensuring it originates from your network as defined in the Cloud SWG Portal. This prompts CTC to signal WSSA/SEP to enter Passive mode.

Static routes defined in VPN client to route WSSA/SEP traffic out direct:

Another alternative is to configure the VPN client with static routes directly to the Cloud SWG data-centers (instead of using the default route back to your corporate VPN server), but there are many Cloud SWG egress ranges that you would have to account for.

The list of Cloud SWG data-center ranges are found in the right-most column of the table at:
https://knowledge.broadcom.com/external/article/167174

This "static route" configuration is another way to ensure that WSSA/SEP traffic routes out directly to the Internet (and not through a 3rd-party VPN tunnel).

======
Official WSSA documentation: WSS Agent Connection Concepts

Additional Information

When traffic is configured to route "tunnel in tunnel" (bad scenario), there are three (3) encapsulating layers:

1. The "core" TCP traffic (from the browser)
2. The WSSA/SEP traffic wrapped in a WSSA VPN tunnel (including the extra encryption and overhead)
3. The 3rd-party VPN client's traffic wrapped in their own VPN tunnel (including their additional encryption and overhead)

At each layer, you are "narrowing" what can be sent through each tunnel.

This is excessive encryption and overhead that will cause known performance problems...especially with video and "large packet" applications that are sensitive to performance and lost packets.

With this problematic configuration ("tunnel in tunnel"), you are increasing the risk of dropping packets: each layer has a risk of dropping packets and that will cascade and impact the other layers.