How does users geo-location work

The following users/devices are automatically geo-located:

• The people using the Watcher browser extension
• The Enterprise Stations for which the "Site" configuration is set to "Automatic"
• The devices that are part of a Kadiska Fleet for which the "Site" configuration is set to "Automatic"

Three factors drive the way these are geo-located:

• the Sites/Gateways configuration
• the path used to send collected performance metrics to the Kadiska platform
• the Kadiska ability to identify users' private IP address used

In addition, in case of a CASB, the geo-location can also depend on Kadiska's ability to identify it automatically.

Path used to send collected performance metrics

In the following sections, we examine all possible scenarios you may encounter. For each scenario, we envisage how the collected data can be sent to the Kadiska platform and how this affect the "Application path" view.

No Site/Gateway configuration, no CASB automatic identification

When using a CASB, all users connect to the application by first passing through the CASB. The collected performance metrics can then be sent either through the same application path (so via the CASB) or directly to the Kadiska platform.

In the first scenario, the situation can be schematized as follows:

At the top of the picture, you see the remote users and onsite users connecting to the applications through the CASB. The red dotted lines correspond to the path of collected data traffic to the Kadiska platform.

At the bottom, you see what the "Application path" dashboard will look like:

• No gateway is identified
• There is no distinction between different types of users
• The ISP identification corresponds to the ISP of the CASB provider
• The users geo-location corresponds to the CASB location

This scenario is also valid for any other types of gateways, that is VPNs and corporate gateways.

In case the collected data do not pass through the CASB but are directly sent to the Kadiska platform, the situation is the following:

This way of collecting the data does only impact the geo-location of remote users. This time, these users are geo-located based on their local public IP addresses (for example their home Internet connection) and their local ISP is identified.

No Site/Gateway configuration, CASB automatic identification

If you do not configure any site and gateway but use one of the major CASB providers automatically recognized by Kadiska, even if you cannot geo-locate the users, you can identify the CASB itself. When the collected data are sent through the CASB, the geolocation and corresponding ISP will be those of the CASB itself.

When the collected data are directly sent to the Kadiska platform without passing through the CASB, the remote users are geo-located based on their local public IP address. Their local ISP is also identified.

Sites and Gateways are configured

When you configure your gateways (corporate gateways, VPNs or CASBs) and your corporate sites, you get a far better view. In this case, your sites are always geo-located based on their country and city configuration. The remote users are geo-located based on the way the collected data are sent to the Kadiska platform, as it was the case in all other scenarios.

When collected data are sent through your gateway, the remote users are geo-located based on the gateway public IP address. The ISP corresponds to the one on which the gateway is directly connected.

In this scenario, please make sure you link your sites configuration to the CASB.

When collected data are sent directly to the Kadiska platform without passing through the gateway, the remote users are correctly geo-located based on their local public IP addresses and local ISP.

In this scenario, please make sure you link your sites configuration to each site corporate gateway (the public IP address(es) of the local router) so that the users are correctly geo-located based on their respective site configuration. Be aware though that the CASB will not be identified in the sites-to-applications path.

Identification of user's private IP address

Assigning a user to a configured site requires the proper identification of the related private IP address used to connect to his/her local network.
The challenge is that a user's device can have multiple IP addresses (when having multiple network interfaces or using virtual environments for example) and can also have dual IP stacks (IPv4 and IPv6) activated at the same time.

In order to correctly identify the IP address used when connecting to monitored business applications, Kadiska performs the following steps:

1. If there is only one IP address, it is kept by default
2. If one of the discovered IP addresses matches a site configuration, then this IP address is kept
3. In a dual stack configuration (IPv4 and IPv6), if collected data contains IPv4 server IP addresses an if the user's device has only one IPv4 private IP address, it is kept
4. The same principle as in step 3 applies to IPv6
5. If none of the previous steps is successful, then the private IP address is left empty

Remarks:

• When the user's private IP address is left empty, he/she is automatically considered to be remote.
• If Watcher is deployed through in-app JavaScript, then the users are always identified by their public IP address. They cannot be linked to configured sites.