Zscaler Introduces Geolocalization

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.

Public link

Please use the above public link if you want to share this noodl on another website.