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?
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:
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.
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:
Full Tunnel Configuration:
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
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.