> For the complete documentation index, see [llms.txt](https://docs.vectra.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.vectra.ai/configuration/coverage/brain-setup/ip-address-classfication.md).

# IP address classfication

To access IP address classification settings, navigate in your Vectra UI to *Configuration → COVERAGE → Data Sources* and then to *Network → Brain Setup > IP Address Classification.*

When you edit this setting, you will be presented with the below dialog:

![](/files/TyxOJAQ7ntoMPKey40zC)

## Introduction

For proper algorithm operation and recognition of traffic directionality within Stream, Investigate, or Recall it is mandatory to accurately identify internal vs external IP space. By default, all RFC-1918 IP space is considered **internal**.

Additionally, Vectra NDR AI detection models do not analyze connections that originate from external IP space. Return traffic for connections that originated internally to external entities is analyzed.

Metadata is still produced for Stream, Investigate, and Recall functionality. Match also processes externally originated connections through the underlying Suricata engine regardless of the IP address classification settings. Vectra Packet Capture is also unaffected by these settings.

## Configuration

Please see the below for details on how each of the IP address classification settings will affect the system.

{% hint style="info" %}
**Please Note:**

**RFC-1918 (Address Allocation for Private Internets) IP space**

As a reminder, the ranges reserved for private addressing from RFC-1918 are below.

For more details, please see: <https://tools.ietf.org/html/rfc1918>

* 10.0.0.0 - 10.255.255.255 (10/8 prefix)
* 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
* 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
* fd00::/8 (IPv6)
  {% endhint %}

#### Internal IP Addresses (CIDR)

* Internal IP addresses are those designated within your network's internal range.
* IP addresses or CIDR blocks entered here will be considered internal to your network.
* Everything else will be considered external.
* By default, all RFC-1918 IP space is considered “internal”.

#### Exclude a Subset of Internal IP Addresses (CIDR)

* Use this area if you have a subset of internal IP addresses listed above that you want to be considered as external to your network.
* For example, if you were going to simulate Command and Control behavior from an internal lab, you should configure the lab IP space as external (by adding it to this section). This allows Detect models properly identify the behavior.

#### Drop IP Addresses (CIDR)

* IP addresses or CIDR blocks entered here will be ignored.
* Any traffic to or from these addresses will not be analyzed by NDR AI models by your system.
* Ignoring traffic by VLAN is supported at the CLI using the `set capture-vlan` command.

**Drop and Exclude Subnet Scenario Examples**

* 10.10.0.0/16 set as Exclude, 10.10.50.0/24 and 10.10.70.0/23 set as Internal, Exclude setting will take precedence and both smaller subnets will be considered as Exclude.
* Similarly, if 10.10.0.0/16 was set as Drop and the others external, the result would be Drop for all.

**CLI Options for Setting Internal, Exclude, Drop**

* After [logging into the CLI of your Brain](/deployment/appliance-operations/console-access-on-appliances.md), include, exclude, and drop networks/vlans can be configured by the below CLI commands.
* The commands also have help that can be shown with the `--help` argument.

```
set capture-network [ networks ] < ( internal | external | drop ) >
set capture-vlan < vlan > drop
show capture-networks
show capture-vlans
```

#### Internal VPN IP Addresses (CIDR)

* Enter any IP ranges allocated to your VPN servers for remote end-user connections.
* This will improve identification and detection model coverage for hosts connecting in via VPN by altering some characteristics of underlying models.
* For more details on [optimizing your system for use with VPN clients](/configuration/coverage/remote-users/optimizing-vectra-for-use-with-vpn-clients.md), please follow the link.

#### Static IP Addresses (CIDR)

* In many customer environments, Vectra’s automated Host Identification (Host ID) is all that is required for customers to have all the pertinent hosts in their environment named and tracked. Generic hosts (IP-x.x.x.x) will inevitably be observed when a host first comes into the environment, but not enough artifacts have been observed to create a stable named host object or attribute its traffic to a previously created host. This can commonly happen when a user plugs in a laptop for the day, but the host is not recognized immediately. Vectra manages this on its own and will attribute traffic for this generic host to the named real host object once it is recognized.
* Many customers also have statically assigned hosts and may not have hostnames in customer DNS. Additionally, Vectra may not directly observe enough artifacts of other types to name the host. If a stable host object never gets created, learning for several models cannot be anchored to generic hosts. This means that some Detections cannot fire and features such as the Host Role cannot function on these generic hosts.
* Enter IP addresses or CIDR blocks representing the statically assigned hosts in your environment in this area.
* Hosts on these IPs or ranges will show as **STATIC-x.x.x.x** in the Vectra UI and will no longer be generic hosts.
* These hosts will have full support for learning and all Detections and features.
* Statically defined hosts will not change name based on observed artifacts - they will remain static until they are no longer configured as such.
* You are free to rename statically assigned hosts as you wish.

**CLI Option for Setting Static Ranges**

This configuration may be completed via CLI commands as `vectra` or other enabled CLI user user on the Brain. See [SSH login process for CLI for more details on accessing the CLI.](/deployment/appliance-operations/ssh-login-process-for-cli.md)

```
vscli > set capture-network --help
Usage: set capture-network [ networks ] < ( internal | external | drop ) >

  Adds a CIDR block or list of CIDR blocks into the capture configuration with
  the specified classification.

  Networks are provided in the form of 10.2.0.0/16

  internal: Networks where hosts should be treated as internal hosts. For IPv4
  RFC1918 addresses are included by default. For IPv6 ULA addresses are
  included by default.

  external: Hosts classified as external are treated as external hosts even if
  they reside in RFC1918 address space. The external classification takes
  precedence over the fact that RFC1918 addresses default to being internal.

  drop: Traffic comming from or going to these networks are dropped.

Options:
  -h, --help  Show this message and exit.
```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.vectra.ai/configuration/coverage/brain-setup/ip-address-classfication.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
