Cloud SWG Announcement: Los Angeles (GUSLA) Data Center Failover Testing - October 21-22, 2026

The Los Angeles, California (GUSLA) Cloud SWG site will undergo a data center failover test beginning on October 21, 2026 starting at 02:00 UTC, lasting for a duration of up to 36 hours. Failover testing is conducted on a regular basis to ensure the platform can gracefully handle a real outage. Carefully review the information below to avoid disruption of service.

Timing

Failover : October 21, 2026 beginning at 0200 UTC

Failback : October 22, 2026 beginning at 0200 UTC

Impact

The following describes what happens to connected clients during the testing window, based on access method:

• WSS Agent and SEP Agent: The service automatically redirects connections to alternate infrastructure within the same geographic location during the testing window.
• IPSec, Proxy Forwarding and Explicit methods will failover to Las Vegas, Nevada (GUSLV) Cloud SWG site if recommendations have been followed in this Broadcom article, Cloud SWG backup sites, hostnames and VIPs for fixed locations.
• Traffic from customer firewalls using IPSec tunnels into Cloud SWG will automatically switch to backup tunnels. If no backup tunnels are configured manual steps will be required by the customer to configure a tunnel into Las Vegas (GUSLV) to avoid an outage.

Cloud SWG Los Angeles (GUSLA) egress IP ranges (provided for convenience; there are no changes):

• 148.64.18.0/24
• 199.19.248.0/24
• 34.186.154.48/28
• 2604:b040:13:2100:1::/80

Cloud SWG Las Vegas (GUSLV) egress IP ranges (provided for convenience; there are no changes):

• 168.149.133.0/24
• 168.149.160.0/24
• 34.186.10.128/28
• 2604:b040:13:2200::/80

Please reference this KB article for all Cloud SWG data center IP ranges.

Required Action

• Prior to October 21, 2026 at 0200 UTC, please ensure that your agents can connect to any Cloud SWG data center to maximize failover opportunities. Although most agents will fail over to Las Vegas, some may failover to other data centers for various reasons. Failure to make these changes could prevent users from connecting to Cloud SWG, accessing third party web applications, or authenticating against the service using the Auth Connector (where applicable).
• Firewall rules regulating connectivity to/from your network to Cloud SWG should be adjusted to allow traffic to pass to the IP networks listed in the KB article above.
• Third party applications that regulate connections by source IP address should be updated to accept connections from the IP networks in the KB article above to ensure traffic proxied through Cloud SWG can reach the applications.
• Auth Connector must be able to communicate with all IP ranges listed in the KB article above, on TCP 443, where applicable.