- Define policy in your Portal that intercepts the Google request to the country you end up redirected to and redirect it to https://www.google.com/ncr.
- This redirect defines a no country redirect. The redirect sets a cookie in your browser for Google not to redirect the request to a country-specific site.
- Using the previous example, the following policy shows where the request originates in North America and redirects to www.google.it instead of remaining on www.google.com.
- This rule states that from Any source to Anywhere and matching google.it yields a Redirect verdict to https://www.google.com/ncr. Because Google redirects to HTTPS, the rule redirects to HTTPS as well. This redirection is especially important when not intercepting SSL. Otherwise the request might redirect to HTTPS by Google as well as a repeat of the country redirect that caused the problem. Consider that when only entering the URL in domain name fashion only (google.com), the browser appends http://and by doing so the request is subject to redirection by the destination site, which in this case is Google. Therefore, the redirect rule with HTTPS along with /ncr sends the request out pure without any reason for Google to redirect.
NOTE - This issue is not a Symantec WSS issue. Symantec has no control of the GEO-mappings that Google maintains. When we are notified, Symantec can make a request to Google to update their GEO Location mappings to reflect the proper location for Symantec's WSS egress IP addresses.
To report IP problems you can go here. Google's official statement says that it can take a month (or sometimes longer) to resolve the issue. Until Google updates their GEO mapping information, use the previous workaround.