Web Security Service (WSS) ingress and egress IP addresses


Article ID: 167174


Updated On:


Web Security Service - WSS


  • What are the IP addresses used to connect to the Symantec Web Security Service (WSS)?
  • What are the data center names and locations?
  • What are the WSS IP addresses and ranges that have to be permitted on firewalls?
  • What is a vPOP and where are they located?
  • What are the WSS ingress and egress subnet ranges?
  • What are the IP addresses used by Integrated Services?


Best Practices based on Connection Type (Access Method)

IPsec:  For fault tolerance, each customer site should have IPsec tunnels established to at least two (2) WSS data centers in the table below, as well as:

  • Only IPsec connections should redirect traffic to an IP address.  All other connections should use WSS data center hostnames.
  • IPsec connections are only accepted by the IPsec specific ingress IP addresses in the table below.
  • IPsec configurations should have dead peer detection (DPD) enabled and a tunnel monitor (ie, IPSLA) configured.
  • IPsec phase 1 lifetime should be 24 hours, and phase 2 lifetime should be four hours.
    • IKEv2 FQDN phase 2 lifetime should be 50 minutes.
  • IPsec backup tunnels should never point to the same "compute POP" (data center) that the primary tunnel is going to.

Explicit over IPsec ("Trans-proxy" forwarding):  Explicit traffic redirection within an IPsec tunnel to WSS should always point to ep.threatpulse.net:80

Explicit and Proxy Forwarding:  For optimal performance and fault tolerance, explicit traffic should be redirected to proxy.threatpulse.net:8080.  This hostname automatically resolves to the nearest WSS data center based on the geo-location of the client's DNS resolver.  In the event of an outage (including planned maintenance), users will be automatically redirected to the nearest available data center.

Should the need to avoid GEO location services with explicit exists, the following WSS explicit IP addresses indicate the VIPs an admin can point to for explicit or Proxy Forwarded traffic.

SEP WTR:  For optimal performance and fault tolerance, explicit traffic should be redirected to sep-wtr.threatpulse.net:8080.  Nearest data center selection is performed automatically by the agent based on the geo location of the end user's public IP address.  No manual configuration is required.

WSS Agent, Unified Agent:  Nearest data center selection is performed automatically by the agent based on the geo-location of the end user's public egress IP address.  No manual configuration is required.


IP Addresses for WSS-Integrated Services


Portal Addresses
Cloud Traffic Controller (CTC) addresses
Auth Manager
PAC File Management Service


WSS ingress and egress IP addresses

Note:  The "ingress ranges" in the third column are also the WSS "egress ranges".

Location (codename) Ingress IP address (IPsec and trans-proxy) Ingress and egress ranges for other access methods and for auth connector
Buenos Aires, Argentina (GARBA1) - vPOP to Sao Paulo
Columbia, South Carolina (GUSCO1)
Des Moines, Iowa (GUSDM1)
Las Vegas, Nevada (GUSLV1)
Los Angeles, California (GUSLA1)
Mexico City, Mexico (GMXMC1) - vPOP to Los Angeles
Montreal, Canada (GCAMO1)
Portland, Oregon (GUSPO1)
Sao Paulo, Brazil (GBRSP1)
Toronto, Canada (GCATO1) - vPOP to Montreal
Washington, DC (GUSAS1)


Auckland, New Zealand (GNZAU1) - vPOP to Sydney

Bangkok, Thailand (GTHBA11) - vPOP to Singapore


Beijing, China (PEK1)

Hanoi, Vietnam (GVNHA11) - vPOP to Singapore -

Hong Kong (GCNHK1)

Jakarta, Indonesia (GIDJK11) -

Kuala Lumpur, Malaysia (GMYKL11) - vPOP to Singapore -

Manila, Philippines (GPHMA11) - vPOP to Jakarta -

Mumbai, India (GINMU1)

Osaka, Japan (GJPOS1)

Seoul, South Korea (GKRSE1)

Shanghai, China (SHA1)

Singapore (GSGRS1)

Sydney, Australia (GAUSY1)

Taipei, Taiwan (GTWTA1)

Tokyo, Japan (GJPTK)

Wellington, New Zealand (GNZWL1) - vPOP to Sydney


Abu Dhabi, UAE (GAEAD1) - vPOP to Mumbai

Amsterdam, the Netherlands (GNLAM1)

Ankara, Turkey (GTRAN11) - vPOP to Frankfurt

Athens, Greece (GGRAT11) - vPOP to Frankfurt

Brussels, Belgium (GBEBR11) -

Bucharest, Romania (GROBU1) - vPOP to Frankfurt 

Copenhagen, Denmark (GDKCP1) - vPOP to Amsterdam

Dubai, UAE (GAEDX1) - vPOP to Zurich

Dublin, Ireland (GIEDU1) -  vPOP to London

Frankfurt, Germany (GDEFR1)

Helsinki, Finland (GFIHE1)

Lisbon, Portugal (GPTLI1) - vPOP to Zurich -

London, England (GGBLO1)

Madrid, Spain (GESMA1) - vPOP to Zurich

Milan, Italy (GITMI1) - vPOP to Frankfurt

Nicosia, Cyprus (GCYNI11) - vPOP to Frankfurt

Oslo, Norway (GNOOS1) - vPOP to Helsinki

Paris, France (GFRPA1) - vPOP to Belgium

Stockholm, Sweden (GSESK1) - vPOP to Helsinki

Tel Aviv, Israel (GILTA1) - vPOP to London

Vienna, Austria (GATVI11) - vPOP to Frankfurt -

Valletta, Malta (GMTVA11) - vPOP to Frankfurt -

Zurich, Switzerland (GCHZU1)


Abuja, Nigeria (GNGAB11) - vPOP to Zurich


Accra, Ghana (GGHAC11) - vPOP to Zurich


Algiers, Algeria (GDZAL11) - vPOP to Frankfurt


Cairo, Egypt (GEGCA11) - vPOP to Frankfurt


Dakar, Senegal (GSNDA1) - vPOP to Zurich


Gaborone, Botswana (GBWGA11) - vPOP to London -

Harare, Zimbabwe (GZWHA11) - vPOP to London -

Johannesburg, South Africa (GZAJB1) - vPOP to London

Lilongwe, Malawi (GMWLI11) - vPOP to London


Luanda, Angola (GAOLU11) - vPOP to London


Lusaka, Zambia (GZMLU11) - vPOP to London


Maputo, Mozambique (GMZMA11) - vPOP to London -

Nairobi, Kenya (GKENA11) - vPOP to London -

Port Louis, Mauritius (GMUPL11) - vPOP to London -

Rabat, Morocco (GMARA1) - vPOP to Zurich

Tunis, Tunesia (GTNTU11) - vPOP to Frankfurt -

Windhoek, Namibia (GNAWI11) - vPOP to London -

POP Types

Compute POP - A point of presence that contains physical compute infrastructure (aka: data center).

vPOP - Virtual point of presence.  vPOPs are physically hosted in a "Compute POP" (data center) in another locale and provide content localization for users in a specific country.  For example: "Paris - vPOP to Belgium" causes users that connect to the Paris vPOP to experience content localized to Paris even though the transaction is physically processed in Belgium.  Performance is maintained for vPOP transactions thanks to our global private network that minimizes use of congested public Internet routes.