> ## Documentation Index
> Fetch the complete documentation index at: https://docs.threataware.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Settings → IP Locations

> Define public IP locations for accurate device geolocation

## What this page is for

At `/settings/ip-location` (singular), the IP Locations page lets you define **Public Locations** — IP ranges mapped to friendly named locations.

<img src="https://mintcdn.com/threatawareltd/IwzdezxNqgZB-5I4/images/core/settings-ip-location.png?fit=max&auto=format&n=IwzdezxNqgZB-5I4&q=85&s=18acbcd218c2b5573dbf9a362721b749" alt="IP Locations page with Public Locations heading and No public locations found empty state" width="1440" height="900" data-path="images/core/settings-ip-location.png" />

By default, Protect geolocates devices using their public IP via standard databases (e.g. resolving `203.0.113.x` to "London, United Kingdom"). That works for most cases but misses some realities:

* VPN egress IPs lump remote workers into one city
* Branch offices on shared upstreams look like the head office
* Cloud-NAT'd traffic gets attributed to the provider's region

Public Locations override the default geolocation for specific IP ranges with your real-world names.

## Adding a location

<Steps>
  <Step title="Click + New Location">
    Top-right.
  </Step>

  <Step title="Provide the location details">
    * **Name** — friendly label (e.g. `HQ London`, `Branch — Manchester`, `VPN — Engineering`)
    * **Public IP / range** — single IP or CIDR (`203.0.113.0/24`)
    * **City** / **Region** / **Country** — what Protect will display for devices behind this IP
  </Step>

  <Step title="(Optional) coordinates">
    Latitude / longitude for accurate map plotting (Device Explorer's globe).
  </Step>

  <Step title="Save">
    Devices currently appearing as the default-geolocated location will re-attribute on the next sync.
  </Step>
</Steps>

## Common patterns

| Pattern         | Example                                           |
| --------------- | ------------------------------------------------- |
| **Office IP**   | `203.0.113.5` → `HQ — London`                     |
| **Office /24**  | `203.0.113.0/24` → `Branch — Manchester`          |
| **VPN gateway** | `198.51.100.0/29` → `VPN — Corporate (egress UK)` |
| **Cloud NAT**   | `35.205.0.0/16` → `Cloud — eu-west-1`             |

## Why it matters

The `location.country` and `location.city` fields are used in many places:

* **Devices grid** Location column
* **Tag rules** like `location.country:United Kingdom`
* **Dashboard** Tag Coverage Map (when location-based tags exist)
* **Geographic risk reporting** — "devices in restricted countries"
* **Saved views** filtered by region

A device incorrectly attributed to "Mountain View, US" because it's behind a VPN to a different region pollutes every downstream view. Correct IP-Locations fix this cleanly.

## Best practices

<AccordionGroup>
  <Accordion title="Document your VPN egress IPs first">
    The most common geolocation surprise — remote workers appearing to be in the VPN exit's city. Configure these first.
  </Accordion>

  <Accordion title="Audit cloud workload IPs">
    Cloud-hosted servers behind NAT or load balancers can attribute to the cloud provider's data centre, not your business region. Override.
  </Accordion>

  <Accordion title="Pair location overrides with tags">
    Once you've got accurate locations, build location-based tags (`UK`, `EMEA`, `APAC`) and use them in Vitals requirements.
  </Accordion>

  <Accordion title="Re-check after IP changes">
    When you change ISPs, restructure NAT, or migrate offices, re-validate your IP Locations.
  </Accordion>
</AccordionGroup>

## Cross-references

<CardGroup cols={3}>
  <Card title="Device Explorer" icon="globe" href="/device-explorer">
    Where the map view uses these locations
  </Card>

  <Card title="Tags & Logic Engine" icon="tag" href="/tags-and-logic-engine">
    Location-based tag rules
  </Card>

  <Card title="Query Language" icon="terminal" href="/query-language">
    Filter by `location.*` fields
  </Card>
</CardGroup>