Zscaler Introduces Geolocalization

In the previous post on this topic, I introduced the problem that security admins face in ensuring uniform security policies for their users in countries not serviced by a local Zscaler PoP. When you implement Zscaler as part of your organization’s zero trust strategy, traffic from users, workloads, IoT, and OT devices in any location is forwarded to one of Zscaler’s globally distributed data centers. With Zscaler’s multitenant architecture, the source IP address of the traffic that egresses from any of these data centers is local to the region where the data center is located and shared between all the traffic egressing from that data center.

For example, when a user in Greece is serviced by a data center in Milan, the traffic egresses with a source IP address mapped to Italy. If the user is serviced by a Zscaler data center in Tel Aviv, the traffic would egress with a source IP address of Israel, and so forth. The content delivered to the user in Greece would then be in Italian or Hebrew, respectively. The local Greek institutions that would restrict access based on perceived locations would block the traffic, too.

There are more than 200 countries in the world, and while Zscaler has a global presence, it is unlikely there will ever be a Point of Presence in all 200+ countries. The solution to the problem of delivering content to these countries lies in assigning a source IP address to traffic that originates from these countries, to an IP address that is perceived as belonging to the country.

_{^{[Figure 1: Map of the global spread of Zscaler data centers]}}

_{^{[Figure 2: Geolocalized IP addresses for users from different countries]}}

When the destination website/server looks up the country based on the source IP address of the traffic in one of the many geolocation databases across the world, the query returns a country that has been mapped to the IP address by Zscaler. The website then renders the content to the user that is local to the region. In the case of government/financial institutions, they would see that the user is in the country and allow access.

How does Zscaler achieve this?

Zscaler achieves this using an in-house Egress NAT solution that translates the source IP address of the traffic egressing from the Zscaler Service Edge to an IP address that has been mapped to the country of interest. The Zscaler Zero Trust Exchange platform determines the source country of the user forwarding the traffic to Zscaler, and then uses this information to NAT the source IP address to the country of interest.

One of the best aspects of this capability is that organizations can selectively apply geolocalization to traffic based on any of the rich criteria available in Zscaler Internet Access (ZIA) today. Let’s take a look at the configuration steps involved.

_{^{[Figure 3: Selecting GeoIP as a Forwarding Method ensures geolocalization]}}

As a ZIA operators/administrators, you can navigate to the Forwarding Control under Policy in the ZIA Admin console and create a policy with the Forwarding gateway method selected as “GeoIP”. If you have other forwarding rules configured already, you can customize the rule order. You can then select the criteria that you want to apply, including users, groups, departments, destinations, source IPs, applications, and so on.

For example, suppose you want the traffic from User A to egress with a geolocalized IP address only to access certain known destination FQDNs. For all other destinations, you want the traffic to flow directly from the Zero Trust Exchange with a non-localized IP address. Or perhaps you want the traffic from this user to egress with an IP address dedicated to your organization. Your rules would look something like this:

Rule 1: User A → Destination FQDN (www.BankOfCountryA.com) → Forwarding Method GeoIP

Rule 2: User A → Destination applications (3rd party SaaS applications) → Forwarding Method Dedicated IP (ZPA Gateway)

Rule 3: User A → Forwarding Method Direct

Note that here, Rule 3 is optional. Any traffic that does not meet Forwarding rule criteria is forwarded directly to the destination using the Zscaler egress IPs.

Incorporating geolocalization into Zscaler’s forwarding policy engine gives admins a powerful tool to create granular policies based on the organization’s needs. The use cases are many, and the solution offers immense flexibility. Here are just a few examples of how geolocalization could be applied:

• A country's finance staff need to access the local finance authority's website, but other users do not
• You want to allow GeoIPs only from a select group of Source IP addresses
• Only specific applications need geolocalization and others do not

Internally, Zscaler ensures there are two aspects covered in this service.

1. The correct IP address is assigned to the traffic based on the source country. The Egress NAT function receives the mapping of the IP address to the country from the Zscaler Central Authority. The Service Edge also maintains a mapping of the Egress NAT functions and the countries for which they have IP addresses. This is also retrieved from the Central Authority and used by the Service Edge to forward the traffic to the appropriate Egress NAT function over a tunnel that includes the metadata to identify the country to which the traffic needs to be mapped. The Egress NAT function uses the metadata to identify the IP address that needs to be assigned to the traffic, does the translation, and egresses the traffic towards the final destination. The reverse path is much the same as the forward path: the IP address is translated back to the IP of the Service Edge, forwarded to the Service Edge, and then onward to the source.
2. The IP address mapping to the country is updated in the geolocation databases. Zscaler has adopted the approach from RFC 8805 - “A Format for Self-Published IP Geolocation Feeds”. Zscaler publishes a list of IP addresses to country mappings that are consumed by geolocation databases. Internally, Zscaler maintains the list in its own database which is used by the Egress NAT function.

Zscaler data centers that offer this service have been carefully selected to be geographically nearest to the country in which the user is located, ensuring minimal latency (which is inevitable in a service such as this).

For example, the traffic of a user in Morocco could be serviced by the Zscaler data center in France. The geolocalization mapping for Morocco would be hosted in Frankfurt. So the traffic would be forwarded by the Zscaler data center in France to the Zscaler data center in Frankfurt, where the source IP address of the traffic would be translated to a Moroccan IP address. The traffic would then egress toward the destination with this new source IP address. Similarly, the internet links from much of South America terminate in Miami, Florida. Therefore, Zscaler’s Miami data center hosts the mapping of IP addresses to all South American countries.

Zscaler Geolocalization is coming soon!

Zscaler Geolocalization ensures content sovereignty in all the content rendered to an end user, wherever they may be. We are excited to announce beta availability of the service starting as early as next month!

Want to try this new feature with your users in locations not serviced by Zscaler PoPs in the same country? Reach out to Zscaler to sign up!