About locations

A location identifies the regions or branches in your network where traffic originates from. A location can be a region or geographic area in your network, such as a CIDR block for an office branch or company headquarters.

Depending on your network and the needs of your organization, you can identify a location with this information:

• Static IP address. Fixed IP addresses or CIDR ranges associated with branches or regions of your network.
• Dynamic IP address. If your organization uses dynamic DNS, you can enter the hostname that’s registered with the dynamic DNS provider. For more information, see Dynamic IP addresses.
• IKE ID for IPsec. If your organization uses dynamic IP addresses and you cannot identify the dynamic DNS host, you can use the Internet Key Exchange (IKE) ID for an IPsec tunnel as a location identifier. You configure the prefix of the identifier in ​SIA​. No IP address or DNS host is required for this configuration. For more information on this location identifier, see IKE ID as an identifier.

📘

Identifying a location by the IKE ID and the PSK of an IPsec tunnel is currently in beta.

When creating a location, remember:

• You need to provide the public IP address of your AD or other local DNS server that is used to communicate with ​SIA​.

• You cannot assign a location IP address to other ​SIA​ locations in your network.

• You cannot configure a location with an IP address that is claimed or used by another organization. If you believe your organization owns an IP address that you cannot configure as a location, contact ​Akamai​ Support.

• For a location, ​SIA​ currently supports a maximum CIDR block of /16 for IPv4 and /48 for IPv6.

• A location configuration requires a policy assignment. If you do not assign a policy to the location, the location is automatically assigned to the default policy. You can assign the same policy to multiple locations or you can create different policies for locations in your network.

• You can enable the Protect DNS in Tunnels setting to protect DNS traffic that passes through an IPsec tunnel with the policy assigned to the location. Even if your organization uses a public DNS server, this traffic is protected.

• You can assign a different policy for traffic that arrives from Zero Trust Client or ​ETP Client​. This applies to clients that are on the corporate network. The policy you select overrides the policy for the location. To learn more about this feature, see Traffic from Clients.

• You can associate a sub-location to a location configuration. For more information, see Sub-locations.

When you create, modify, or delete a location or sub-location, you need to deploy these updates to the ​SIA​ network. Changes to location settings, as well as other configuration settings such as policies or custom lists, are captured in the Pending Changes window for you to review. After you click the deploy button, the deploy operation typically completes in 20-30 seconds.

An enterprise can add a maximum of 7,000 CIDR entries for locations or sub-locations. If your organization needs to add more CIDR entries, contact your ​Akamai​ representative.

📘

The ANY query type retrieves all records on a specific domain. The following applies:

• From a known location, DNS requests with the ANY query type are rate limited
• From a location with unidentified IP addresses, ​SIA​ does not resolve or log queries with the ANY query type.

Dynamic IP Addresses

Dynamic DNS (DDNS) providers allow organizations to register IP addresses that change dynamically with a persistent DNS hostname. Some organizations cannot use static IP addresses from their Internet service provider (ISP) and instead rely on IP addresses that are assigned dynamically and change from time to time.

If your Internet connection uses dynamic IP addresses, you can use a dynamic DNS provider to assign a permanent DNS hostname for a location. When the IP address changes, your router can then communicate with the dynamic DNS provider and update that hostname with the associated dynamic IP addresses.

By configuring a location with a hostname that's registered with the dynamic DNS provider, ​SIA​ can detect when the IP address assigned to your location is changed by the ISP.

The Location page alerts administrators when a location is assigned a domain that no longer resolves to a valid IP address. Administrators can also see if there is a problem with resolution when creating or modifying a location with dynamic DNS. Errors occur when no response is detected from the IP address or a domain resolves to a private or reserved IP address.

To see which locations generate invalid DNS errors, administrators can download a spreadsheet with these locations and configure a user to receive an email notification for system issues. On the Locations page, administrators can download a spreadsheet that contains locations with invalid DNS entries. You can use this spreadsheet to identify the location configurations that require immediate attention. If an ​SIA​ user or administrator is configured to receive email notifications for system issues, the user or administrator receives a notification that lists locations with invalid DNS entries.

To resolve these issues, administrators can update the location configuration or they can correct the dynamic DNS entries registered with the dynamic DNS provider.

📘

Considerations

• ​SIA​ resolves dynamic IP addresses every 24 hours. While most ISPs allocate IP addresses for a long period of time, there may be a window of time when the IP address changes before ​SIA​ discovers it. If this occurs, the default policy applies. Until the new IP address is discovered, events and network traffic are reported under the Unidentified IPs location.

• Make sure your dynamic DNS hostname resolves to an IP address that is not specified in another ​SIA​ location.

IKE ID as an identifier

If you don’t want to identify a location with an IP address or you’re unable to identify the dynamic DNS host that your organization uses for dynamic IP addresses, you can configure an IKE ID. The IKE ID and its pre-shared key (PSK) is used to validate and secure communication between two hosts or network entities across an IPsec tunnel. This identifier requires that you set up an IPsec tunnel between your location and ​SIA​. For instructions on setting up IPsec, see Set up IPsec tunnels.

You configure the IKE ID in ​​SIA​​ and provide it in your SD-WAN solution when you set up an IPsec tunnel. The IKE ID consists of a custom prefix that you configure and a predefined suffix that includes your ​​SIA​​ configuration ID and the location ID. A PSK is also required and provided in both ​SIA​ and the SD-WAN solution.

This location configuration is beneficial to organizations that use the multi-tenancy feature. If your organization has multiple tenants, you can create IPsec tunnels that connect a location in your organization to multiple, separate tenants. Traffic is then able to travel from a single location to your tenants. If your tenants share the same public address, the IKE ID location identifier allows a tenant to report the internal IP address of the user’s device.

Locations with unidentified IP addresses

On the Locations pages, you can choose to allow or block DNS traffic from unidentified locations. Traffic is considered unidentifiable if IP addresses are not associated with a location configuration and therefore, unknown to SIA.

If you allow traffic from unidentified IP addresses or locations, this traffic is automatically assigned the default policy. You can modify the settings of the default policy.

If you choose to block unidentified IP addresses, you can define the autonomous system numbers (ASNs) that you want to allow as exceptions to the block action. Alongside the setting where you blocked unidentified locations, you can list the ASNs that you want to allow. You cannot provide reserved ASNs. These ASNs and ASN ranges are reserved: 0, 23456, 64496-131071, and 4200000000-4294967295.

Sub-locations

​SIA​ also allows you to define sub-locations. Sub-locations are associated with locations. A sub-location represents a segment in your network that's routed to the Internet with the same IP address as the parent location. You can assign a different policy to a location and its sub-locations, allowing you to define granular access to segments of your network.

When creating a sub-location, note that:

• You can configure sub-locations with IPv4 in the private address space (RFC 1918) and with IPv6 as long as they use site-local (fec0::/10) and unique local addresses (fc00::/7).

• Internal IP masking when creating sub-locations is enabled by default. You can configure sub-locations with a subnet that’s up to /28 for IPv4 or /56 for IPv6. You can disable this option to configure addresses with a subnet that’s up to /32 for IPv4 or /128 for IPv6.

• Multiple sub-locations can use the same IP address as long as they are associated with different locations.

• You can deploy a sub-location in a separate deployment from the parent location.

• If a sub-location consumes too many resources, for example, as a result of too many connections, a rate limit is triggered on the sub-location. The rate limit may also be triggered on the parent location and other associated sub-locations to avoid latency issues or service interruption. To resolve this issue, you can configure the sub-location as a location with a new public IP address. This ensures that the rate limit is applied only to the new location and it's not applied to the original location or the other sub-locations.

• If you do not assign a policy to a sub-location, the policy of the parent location is automatically assigned.

• If there is a conflict between the policy that's assigned to a location and sub-location, the policy action for the location takes precedence only when it applies the bypass or block action to a domain.

• You cannot assign a sub-location while you're configuring or managing a policy. You can only assign a policy to a sub-location while creating or managing a sub-location on the Locations page.

• If your organization uses HTTP Forwarder, make sure you enable the proxy in all policies that are associated with the sub-location and the location. Without enabling the proxy, the forwarder directs traffic from the sub-location to the origin.

Traffic from Clients

Depending on the needs of your organization, you may need to apply a specific policy to traffic that arrives from Zero Trust Client or ETP Client and a different policy to traffic that arrives from devices without the client.

When you create or modify a location, you can assign a policy to traffic that's from the client. A client policy overrides the location policy. To assign a different policy to client traffic, see Override location policy for the client.

📘

The client policy only applies to traffic that is on your organization’s network

As an administrator, you can assign one policy to a location, another policy to client traffic, and a separate policy to a sub-location. These policies have this priority:

1. Sub-location policy
2. Client policy
3. Location policy

If there is a conflict, the sub-location policy will take precedence over the client policy and the location policy.