Web Security Service (WSS) 2021 POP Optimization

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

What is the purpose and impact of the optimization?
What WSS POPs are physically unique?

Resolution

Overview

Starting in January 2021, Symantec will begin renaming select points of presence (POPs) to better reflect their post-Google Cloud migration locations. As a result, some POPs will be renamed appropriately and we will also start indicating the type of each POP (“VPOP” or “compute POP”). These changes will also allow us to scale our existing POPs more efficiently and dramatically reduces the need for new IP ranges as we add capacity.

The changes will not negatively impact your performance because no compute POPs are being removed as part of this process. Some redundant IP ranges assigned to WSS Agent infrastructure will be removed because the IP addresses are no longer necessary now that we are fully migrated to Google Cloud. No IPsec IP addresses will be removed so your existing tunnel configurations will continue to function, as long as you are using a supported IPsec ingress IP address.

Any preparation required for the optimizations will be communicated to customer administrators via normal communications procedures prior to each POP-specific maintenance window. Most of the changes are very low-impact in nature but be sure to review the announcements carefully.

What to expect:

• Some POPs will be renamed to better reflect their actual location under the new Google Cloud network. This will help customers connecting via IPsec to more accurately select the nearest compute POP.
• Some VPOP names will go away. For example, Dallas, Chicago, and Denver have been using compute in Des Moines since the completion of the migration in 2020. Therefore, maintaining those VPOP names is unnecessary moving forward.
• Many POPs will see a reduction in the number of IP ranges needed to support our WSS Agent infrastructure. Our agent technologies will automatically adapt to any changes. IPsec customers who are pointing to the correct IP addresses will not be impacted by changes to our agent infrastructure. 
• IPsec ingress IP addresses will be maintained, although you may find it beneficial to adjust which POPs you utilize as a primary and secondary so that you do not have both tunnels pointed to the same compute POP. 
• IPsec and all forms of explicit redirection will no longer be accepted into ingress IP addresses designated for WSS Agent use. So be sure to only connect IPsec tunnels to the IP addresses specifically designated for IPsec. 

 

POP Types

Moving forward, our published POP list will include the type of POP for transparency. There are two types:

1. Compute POP - A point of presence that contains physical compute infrastructure.
2. VPOP - Virtual point of presence. VPOPs are hosted in a compute POP in another locale and provide content localization for users in a specific country. Performance is maintained for VPOP transactions thanks to our global private network that minimizes use of congested public internet routes.

 

Background

The WSS migration to Google Cloud in Spring 2020 required “mapping” old data centers to Google Cloud Regions in order to make IPsec migration seamless for thousands of customers. The mapping was accomplished by simply moving the IP addresses from the old data centers to the nearest Google Cloud Region, collectively saving customers tens of thousands of work-hours by removing the need for them to change their tunnel configurations. While this mapping was extremely helpful in simplifying the migration for our IPsec customers, it is now a hindrance to transparency and can make selecting the nearest POP more difficult.

Thanks to its global private network and extensive interconnects with carriers, content providers, peering exchanges, and CDNs, our Google Cloud regional POPs are able to service a much larger geographical area than infrastructure hosted in colocation data centers, resulting in a smaller POP count, but better overall coverage. As a result, there were instances where a single Google Cloud region inherited IP addresses for more than one of our colo data centers.

 

Examples

During the migration, Google’s US Central Region, located in Iowa, became the home for the WSS IP addresses and infrastructure previously belonging to Dallas, Denver, and Chicago. Therefore, ever since the Google Cloud migration, Dallas, Denver, and Chicago have been VPOPs leveraging compute located in Iowa. There is no benefit in keeping those POP names since they are all really just one physical compute POP. The resulting Iowa POP will be designated “Des Moines.” Some VPOPs will not be renamed because they provide localization for a specific country.

 

No Adverse Changes to the Data Path

The path that your traffic takes will not degrade with these changes. In fact, in some cases, agent users will begin to leverage a slightly closer POP. This can happen when a VPOP is renamed to more accurately reflect the location of its corresponding compute. When a VPOP name is changed, it’s egress IP address geo-location is also changed to reflect the location of the compute POP.