Cloud SWG (formerly known as WSS) hostnames for explicit and proxy forwarding
Article ID: 208150
Updated On:
Products
Issue/Introduction
What are the in-country specific hostnames for explicit proxy, SEP Web and Cloud Access protection and/or proxy forwarding redirection methods?
What are the additional Cloud SWG endpoints to avoid port exhaustion issues using explicit or proxy forwarding access methods?
Environment
Explicit, SEP Web and Cloud Access protection and Proxy Forwarding Access methods
Cause
Users accessing Cloud SWG via SEP Web and Cloud Access protection, Explicit or Proxy Forwarding access methods GEO located to wrong Cloud SWG datacenter
Port exhaustion causing users to experience TCP connection and performance problems going through Cloud SWG service from on-premise NAT gateways, or on-premise ProxySG servers.
Resolution
The following guide offers Cloud SWG administrators the ability to
- Add custom entries into PAC files to force traffic to country specific Cloud SWG data centers (Alternate Options for Explicit Redirection)
and/or
- Point to multiple Cloud SWG explicit endpoints to balance traffic across multiple Cloud SWG pods and avoid port exhaustion issues with Cloud SWG (Multiple hostnames for Proxy Forwarding)
WARNING*: These options should only be used by experienced individuals who understand the implications of manual traffic redirection. Manual data center selection may result in poor performance, reduced fault tolerance, and invalidation of relevant SLA claims.
Alternate Options for Explicit Redirection
The table below provides country-specific hostnames for explicit traffic redirection, allowing customers to force traffic to a specific data center or set of data centers within a country, where applicable. This method of redirection is not recommended because it limits the number of available data centers for fault tolerance, removes Symantec’s ability to control which data centers users connect to compensate for outages and maintenance events, and may result in poor performance for roaming users. In the unlikely event that all data centers within a country are simultaneously unavailable, the service will redirect traffic to the nearest alternate data center outside of the country.
Multiple hostnames for Proxy Forwarding
Customers experiencing port exhaustion issues with explicit or proxy forwarding access method described above, have the option to redirect explicit and proxy forwarding traffic to up to six hostnames per data center; each resolving to a unique IP address, per this naming convention:
[data center codename]-vip[1-6].threatpulse.net
Where:
- [data center codename] is a codename from the table below.
- [1-6] is a number 1 through 6 for each of the available six IP addresses.
Using the Tokyo (GJPTK1) data center as an example, the available hostnames, each resolving to a different public ingress IP address, are:
- gjptk1-vip1.threatpulse.net
- gjptk1-vip2.threatpulse.net
- gjptk1-vip3.threatpulse.net
- gjptk1-vip4.threatpulse.net
- gjptk1-vip5.threatpulse.net
- gjptk1-vip6.threatpulse.net
CHINESE HOSTNAMES:
Hostnames in China will use a different format. They will use <hostname>.wss.broadcom.cn instead of <hostname>.threatpulse.net. This hostname change is necessary due to Chinese regulations which Symantec/Broadcom must abide by. The Chinese hosts will also have the six different VIPs as explained in the example above for Tokyo (gjptk1).
Cloud SWG hostnames
| AMERICAS | ||
| Location (Codename) | Ingress Hostname* (explicit and proxy forwarding) | Country-specific ingress hostname |
| Bogota, Columbia (GCOBO1) (Available on May 7, 2024) | gcobo1-vip1.threatpulse.net | co.proxy.threatpulse.net |
| Buenos Aires, Argentina (GARBA1) | garba1-vip1.threatpulse.net | ar.proxy.threatpulse.net |
| Columbia, South Carolina (GUSCO1) | gusco1-vip1.threatpulse.net | us.proxy.threatpulse.net |
| Dallas, Texas (GUSDA1) | gusda1-vip1.threatpulse.net | us.proxy.threatpulse.net |
| Des Moines, Iowa (GUSDM1) | gusdm1-vip1.threatpulse.net | us.proxy.threatpulse.net |
| Las Vegas, Nevada (GUSLV1) | guslv1-vip1.threatpulse.net | us.proxy.threatpulse.net |
| Los Angeles, California (GUSLA1) | gusla1-vip1.threatpulse.net | us.proxy.threatpulse.net |
| Mexico City, Mexico (GMXMC1) | gmxmc1-vip1.threatpulse.net | mx.proxy.threatpulse.net |
| Montreal, Canada (GCAMO1) | gcamo1-vip1.threatpulse.net | ca.proxy.threatpulse.net |
| Portland, Oregon (GUSPO1) | guspo1-vip1.threatpulse.net | us.proxy.threatpulse.net |
| Sao Paolo, Brazil (GBRSP1) | gbrsp1-vip1.threatpulse.net | br.proxy.threatpulse.net |
| Toronto, Canada (GCATO2) | gcato2-vip1.threatpulse.net | ca.proxy.threatpulse.net |
| Washington, DC (GUSAS1) | gusas1-vip1.threatpulse.net | us.proxy.threatpulse.net |
| APAC | ||
| Auckland, New Zealand (GNZAU1) | gnzau1-vip1.threatpulse.net | nz.proxy.threatpulse.net |
| Beijing, China (ACNBJ2) | acnbj2-vip1.wss.broadcom.cn | cn.proxy.wss.broadcom.cn |
| Delhi, India (GINDE1) | ginde1-vip1.threatpulse.net | in.proxy.threatpulse.net |
| Hong Kong, China (GCNHK1) | gcnhk1-vip1.threatpulse.net | hk.proxy.threatpulse.net |
| Melbourne, Australia (GAUME1) | gaume1-vip1.threatpulse.net | au.proxy.threatpulse.net |
| Mumbai, India (GINMU1) | ginmu1-vip1.threatpulse.net | in.proxy.threatpulse.net |
| Osaka, Japan (GJPOS1) | gjpos1-vip1.threatpulse.net | jp.proxy.threatpulse.net |
| Seoul, South Korea (GKRSE1) | gkrse1-vip1.threatpulse.net | kr.proxy.threatpulse.net |
| Shanghai, China (ACNSH2) | acnsh2-vip1.wss.broadcom.cn | cn.proxy.wss.broadcom.cn |
| Singapore (GSGRS1) | gsgrs1-vip1.threatpulse.net | sg.proxy.threatpulse.net |
| Sidney, Australia (GAUSY1) | gausy1-vip1.threatpulse.net | au.proxy.threatpulse.net |
| Taipei, Taiwan (GTWTA1) | gtwta1-vip1.threatpulse.net | tw.proxy.threatpulse.net |
| Tokyo, Japan (GJPTK1) | gjptk1-vip1.threatpulse.net | jp.proxy.threatpulse.net |
| EMEA | ||
| Abu Dhabi, UAE (GAEAD1) | gaead1-vip1.threatpulse.net | ae.proxy.threatpulse.net |
| Amsterdam, the Netherlands (GNLAM1) | gnlam1-vip1.threatpulse.net | nl.proxy.threatpulse.net |
| Ankara, Turkey (GTRAN1) | gtran1-vip1.threatpulse.net | tr.proxy.threatpulse.net |
| Bucharest, Romania (GROBU1) | grobu1-vip1.threatpulse.net | ro.proxy.threatpulse.net |
| Copenhagen, Denmark (GDKCP1) | gdkcp1-vip1.threatpulse.net | dk.proxy.threatpulse.net |
| Dover, England (GGBDO1) | ggbdo1-vip1.threatpulse.net | uk.proxy.threatpulse.net |
| Dubai, UAE (GAEDX1) | gaedx1-vip1.threatpulse.net | ae.proxy.threatpulse.net |
| Dublin, Ireland (GIEDU1) | giedu1-vip1.threatpulse.net | ie.proxy.threatpulse.net |
| Frankfurt, Germany (GDEFR1) | gdefr1-vip1.threatpulse.net | de.proxy.threatpulse.net |
| Helsinki, Finland (GFIHE1) | gfihe1-vip1.threatpulse.net | fi.proxy.threatpulse.net |
| Johannesburg, South Africa (GZAJB1) | gzajb1-vip1.threatpulse.net | za.proxy.threatpulse.net |
| London, England (GGBLO1) | ggblo1-vip1.threatpulse.net | uk.proxy.threatpulse.net |
| Madrid, Spain (GESMA1) (Retiring on May 29, 2024) | gesma1-vip1.threatpulse.net | es.proxy.threatpulse.net |
| Madrid, Spain (GESTO1) (Available on May 1, 2024) | gesto1-vip1.threatpulse.net | es.proxy.threatpulse.net |
| Milan, Italy (GITMO1) | gitmo1-vip.threatpulse.net | it.proxy.threatpulse.net |
| Oslo, Norway (GNOOS1) | gnoos1-vip1.threatpulse.net | no.proxy.threatpulse.net |
| Paris, France (GFRPA1) (Retiring on May 30, 2024) | gfrpa1-vip1.threatpulse.net | fr.proxy.threatpulse.net |
| Paris, France (GFRVE) (Available on May 2, 2024) | gfrve1-vip1.threatpulse.net | fr.proxy.threatpulse.net |
| Riyadh, Saudi Arabia (GSARI1) | gsari1-vip1.threatpulse.net | sa.proxy.threatpulse.net |
| Stockholm, Sweden (GSESK1) | gsesk1-vip1.threatpulse.net | se.proxy.threatpulse.net |
| Tel Aviv, Israel (GILTA2) | gilta2-vip1.threatpulse.net | il.proxy.threatpulse.net |
| Warsaw, Poland (GPOWA1) | gpowa1-vip1.threatpulse.net | pl.proxy.threatpulse.net |
| Zurich, Switzerland (GCHZU1) | gchzu1-vip1.threatpulse.net | ch.proxy.threatpulse.net |
* Before redirecting explicit or proxy-forwarding traffic to POP or country-specific hostnames, be sure to review the information at the top of this article to avoid performance and fault tolerance issues. IPsec connections must use the IPsec ingress IP address. Please see article 167174 for details.
Feedback
