Configuring Tanium Client peering

Overview of Tanium Client peering settings

Peering settings define the subnet boundaries of the linear chains in which Tanium Clients form peer relationships. Peering settings are designed to optimize network resources that are required to manage endpoints by ensuring that most data transmission is distributed among the low-latency, high-bandwidth links of local area networks (LANs). Using mostly LAN links dramatically reduces resource use over the wide area network (WAN).

For details about how Tanium Client peering works and related concepts, see Client peering.

You can configure a custom listening port for communication between Tanium Clients, or you can configure the Tanium Client to periodically select a new listening port at random, instead of using a fixed port for communications from peers. See Customize listening ports.

Use the default client peering settings to optimize network resources when all endpoints on a subnet defined by the default /24 address mask share a high-speed local connection, or when you do not have much information about the enterprise network. Work with network administrators and Tanium Support to configure a few key settings that further optimize peer communication based on the characteristics of your network. Focus on the following objectives when tuning the settings:

LAN peering only: The default address mask setting is designed to prevent Tanium Client peering across WANs.
Separated subnets: Specify more granular exceptions to the boundaries that the address mask setting defines. For example, within a subnet that the address mask setting defines, you might have a smaller subnet that crosses WAN links. In this case, you can define separated subnets within that smaller subnet so that its clients do not peer across the WAN links. For more information, see Configure separated subnets.
Isolated subnets: Specify the addresses of subnets and endpoints for which you want to disable Tanium Client peering. You can configure isolated subnets that are standalone subnets or that comprise smaller linear chains within the chain that the address mask setting defines (see Figure 1). For more information, see Configure isolated subnets.
Intentional subnets: Specify multiple public IP addresses that belong to a single site to that allow peering among clients that are behind network address translation (NAT) and that have different public IP addresses within that site.

When a Tanium Client registers through Tanium™ Cloud, Tanium Cloud evaluates peering settings and applies the most restrictive rule to determine the subnet for that client. For example, if the default address mask defines a /24 subnet, and the separated subnets configuration defines a /26 subnet, Tanium Cloud applies the peering boundaries of the separated subnet to a client that has an IP address within the bounds of both.

Figure 1 illustrates a deployment with separated, isolated and intentional subnets.

	Address mask When each Tanium Client registers, Tanium Cloud sends the client a neighborhood list. This is a list of adjacent clients that are optimal for peering and that are within the /24 subnet boundaries that the address mask setting defines.
	Separated subnets configuration Upon evaluating the separated subnets configuration, Tanium Cloud applies exceptions that define smaller linear chains that are contained within the /24 address mask chains.
	Isolated subnets configuration Tanium Cloud evaluates the isolated subnets configuration to define linear chains for subnets in which the clients do not peer with each other.
	Intentional subnets configuration TaaS evaluates the intentional subnets configuration to determine clients that can peer with each other even when they are behind network address translation (NAT) and have different public IP addresses.

Configure separated subnets

Configure separated subnets to specify more granular exceptions for Tanium Client peering than the default /24 subnet boundaries.

After you configure separated subnets, Tanium Clients take two to six hours (the randomized client-reset interval) to finish applying all the changes associated with the new configuration.

A user role with the Read Separated Subnets permission is required to view the separated subnets configuration. The Write Separated Subnets permission is required to create, modify, or delete the separated subnets configuration. The Admin reserved role has these permissions.

Figure 1 shows an example deployment with separated subnets.

Add subnets

From the Main menu, go to Administration > Configuration > Subnets.
In the Separated Subnets section, click New Subnets.
Enter each subnet in CIDR format using separate lines or commas as delimiters. Use the ; or # character before any optional comments.
See the following example:
192.168.0.0/26 #This is a data center subnet.
192.168.2.0/26 ;This is a branch office subnet.
Click Save.

Edit subnets

From the Main menu, go to Administration > Configuration > Subnets.
Select one of the Separated Subnets and click Edit.
Edit the subnet (CIDR) and Comment, and click Save.

Configure isolated subnets

Configure isolated subnets to disable client peering for a specified list of subnet and endpoint IP addresses. If the IP address of a Tanium Client is in an isolated subnet, Tanium Cloud sends that client an empty peer list to prevent the client from participating in peering.

After you configure isolated subnets, Tanium Clients take two to six hours (the randomized client-reset interval) to finish applying all the changes associated with the new configuration.

Configure isolated subnets for Tanium Clients that are in VPNs. VPN clients have local IP addresses in a special VPN address block, but their host endpoints are actually not close to each other. VPN clients would use WAN links for peering and latency would be significantly greater than for client-to-server connections.

You might find it convenient to use isolated subnets to disable peering in other cases, such as for testing or debugging peering when you have to troubleshoot network issues. Note that disabling peering causes Tanium Clients to consume more network resources in terms of bandwidth and client-server connections over the WAN. For troubleshooting cases, after you resolve the network issues, the best practice is to remove the clients from the isolated subnets configuration so that they resume peering.

A user role with the Read Isolated Subnets permission is required to view the isolated subnets configuration. The Write Isolated Subnets permission is required to create, modify, or delete the isolated subnets configuration. The Admin reserved role has these permissions.

Figure 1 shows an example deployment with isolated subnets.

Add subnets

From the Main menu, go to Administration > Configuration > Subnets.
In the Isolated Subnets section, click New Subnets.
Enter each subnet in CIDR format using separate lines or commas as delimiters. Use the ; or # character before any optional comments.
See the following example:
192.168.0.0/26 #This is a data center subnet.
192.168.2.0/26 ;This is a branch office subnet.
Click Save.

Edit subnets

From the Main menu, go to Administration > Configuration > Subnets.
Select one of the Isolated Subnets and click Edit.
Edit the subnet (CIDR) and Comment, and click Save.

Configure intentional subnets

Overview of intentional subnets

In a network configuration that uses network address translation (NAT), the local IP addresses of Tanium Clients in the same local area network (subnet) might be mapped to different NAT IP addresses for communication with Tanium Cloud. The default Tanium peering settings allow clients in that subnet to peer with each other only if they share the same NAT IP address. If clients in the same subnet are assigned to different NAT IP addresses, they can peer with each other only if you assign them to an intentional subnet that specifies the full range of NAT IP addresses for that subnet. Without an intentional subnet, each client with a different NAT IP address establishes a leader connection to Tanium Cloud. Network traffic is higher in a deployment with more leader connections, especially when clients download package files for running actions. Therefore, configuring intentional subnets can increase peering and reduce traffic, particularly in deployments where many clients use NAT when connecting to Tanium Cloud over the Internet.

Intentional subnets require Tanium Client 7.4.7.1130 or later.

The following table shows examples of Tanium Clients that do or do not require intentional subnets to enable peering. The example IP addresses are listed as they would appear on the Administration > Configuration > Client Status page, where the Network Location (from client) column shows the pre-NAT IP addresses and the Network Location (from server) column shows the NAT IP addresses. In this example, the AddressMask platform setting specifies a /24 subnet mask, which is the default peering range (see ).

Table 1: Example of Tanium Client peering requirements
Tanium Client	Network Location (from client)	Network Location (from server)	Intentional subnet required for peering?
TC‑UK‑1	31.0.0.11	31.0.0.11	No: The clients do not use NAT. Therefore, even though their IP addresses differ, they can peer because they are in the same subnet within the default peering range (AddressMask = /24).
TC‑UK‑2	31.0.0.12	31.0.0.12
TC‑US‑1	172.16.0.11	14.0.0.11	No: The clients can peer because they use the same NAT address.
TC‑US‑2	172.16.0.12	14.0.0.11
TC‑HQ‑1	10.0.0.11	98.0.0.1	Yes: The clients are in the same subnet within the default peering range, but the AddressMask setting does not apply because their NAT IP addresses differ. Without an intentional subnet, Tanium Cloud interprets the different NAT IP addresses as an indication that the clients are in different subnets and therefore prevents peering.
TC‑HQ‑2	10.0.0.12	98.0.0.2

Before you begin

You can define intentional subnets using either of the following methods:

Intentional subnet sites: In Tanium Console, you can specify a Site name for an intenional subnet site and the subnets that belong to that Site. Clients in the subnets that belong to a single site can peer with one another.
PeerNeighborhood client setting: You can configure the same neighborhood name for the PeerNeighborhood setting on each client that can peer. You can use this setting to define intentional subnets in the following scenarios:
- You want to allow clients that have a wide variety of NAT IP addresses to peer, and the variety of IP addresses makes subnets difficult to define, or subnets overlap among sites that need to remain isolated.
- You want to deploy clients that are always allowed to peer, regardless of NAT IP addresses, such as virtual machines in a cloud environment.
- You want to manually allow specific clients to peer.

To determine the approriate method to define intentional subnets, and the appropriate Site names and subnet CIDR values or PeerNeighborhood names:

From the Main menu, go to Administration > Configuration > Client Status and identify endpoints that are in the same subnet [based on their Network Location (from client)] but are not peering because their NAT IP addresses [Network Location (from server)] differ.

Tanium Cloud considers pre-NAT IP addresses to be in the same subnet based on the AddressMask setting.
Choose appropriate Site or PeerNeighborhood names for the endpoints that you identified. For example, you might have a HeadQuarters site for endpoints in the headquarters subnet and a NAM site for endpoints in a North America branch office subnet.
Inventory the NAT IP addresses of each site to determine the appropriate method to define the intentional subnets and, if applicable, the CIDR values to enter.
- If the subnets are reasonable to define and do not overlap among sites that need to remain isolated, use the NAT IP addresses to determine the appropriate subnets in intentional subnet sites.
  The best practice is to enter the smallest subnet ranges possible that include the identified endpoints while allowing for potential changes to their NAT IP addresses. As an example, for the clients TC-HQ-1 (98.0.0.1) and TC-HQ-2 (98.0.0.2) in Table 1, you might configure a Site named HeadQuarters with one of the following subnets, which are listed in descending order in terms of the size of their IP address range:
  - 98.0.0.0/24: Peering is allowed for all Tanium Clients with NAT IP addresses in the range 98.0.0.0 to 98.0.0.255. If TC-HQ-1 and TC-HQ-2 are assigned to new NAT IP addresses within that range, they can still peer.
  - 98.0.0.0/30: Peering is allowed for all Tanium Clients with NAT IP addresses in the range 98.0.0.0 to 98.0.0.3. If the NAT IP address of TC-HQ-1 changes to 98.0.0.3 and TC-HQ-2 stays at 98.0.0.2, they can still peer. However, if TC-HQ-1 changes to 98.0.0.4, it cannot peer with TC-HQ-2.
  - 98.0.0.1/32 and 98.0.0.2/32: Peering is allowed only for Tanium Clients with NAT IP addresses 98.0.0.1 and 98.0.0.2. TC-HQ-1 and TC-HQ-2 cannot peer if their NAT IP addresses change.
  After you determine the appropriate subnet ranges, follow the steps in Define intentional subnets using Sites.
- If the IP addresses are too varied to define reasonable subnets, or if subnets overlap among sites that need to remain isolated, see Define intentional subnets using the PeerNeighborhood client setting.
Consider whether newly deployed clients in certain networks might have different NAT IP addresses but are allowed to peer. If so, see Define intentional subnets using the PeerNeighborhood client setting.

After you configure intentional subnets, Tanium Clients take from two to six hours (the randomized registration reset interval) to finish applying all the changes associated with the new configuration.

Define intentional subnets using Sites

Tanium Cloud can identify an intentional subnet by a Site name that you specify and allow peering among all Tanium Clients that are in the subnets you add to that Site.

Add subnets

From the Main menu, go to Administration > Configuration > Subnets.
In the Intentional Subnets section, click New Subnets.
Enter a name to identify the Site that comprises the intentional subnets.
(Optional) Enter a comment to help other users understand the function of the subnet in your organization.
In the New subnet CIDRs field, enter each subnet in CIDR format (a.b.c.d/x) using separate lines or commas as delimiters.
Click Save.

Edit subnets

From the Main menu, go to Administration > Configuration > Subnets.
Select one of the Intentional Subnets and click Edit.
Edit the subnet (CIDR) and Comment, and click Save.

Define intentional subnets using the PeerNeighborhood client setting

Use the PeerNeighborhood client setting to designate certain clients that are allowed to peer with one another. You can apply the setting during or after client deployment. Tanium Cloud allows these clients to peer, regardless of the NAT IP of each client.

Set the same PeerNeighborhood name for all clients in each site that are allowed to peer. For example, if you have lab sites "Lab East" and "Lab West," you can set the PeerNeighborhood client setting for all clients in each site to Lab-East and Lab-West respectively.

For methods to modify the PeerNeighborhood client setting, see .

Verify intentional subnets

After you configure intentional subnets, wait for the next client registration reset interval before verifying that the subnets work as expected. See . In the Administration > Configuration > Client Status page, the Network Location (from client) column shows the pre-NAT IP addresses and the Network Location (from server) column shows the NAT IP addresses.

Verify or remediate Tanium Client peering and leader connections

The Client Status page displays information about the state of Tanium Client registration and connectivity, and enables you to deploy actions to remediate issues.

You require a role with Client Status read permission is required to see the Client Status page. The Admin reserved role has this permission.

View the status of Tanium Client registration and communication

From the Main menu, go to Administration > Configuration > Client Status.
(Optional) To display status details only for specific Tanium Clients, edit the default filter settings, such as the registration intervals and connection status.

The following table lists the information that the Client Status page displays for each Tanium Client.

Certain columns are hidden by default. To display or hide columns, click Customize Columns and select (display) or deselect (hide) column names.

Table 2: Client Status columns
Column	Description
Host Name	Endpoint host name.
Network Location (from client)	Client IP address returned from a sensor on the client.
Network Location (from server)	Client IP address recorded on Tanium Cloud during the last registration.
Direction	A circle represents the client and arrows represent its connections. For a list of possible connection states, see Table 3.
Valid Key	No indicates an issue with the public key that the Tanium Client uses to secure communication with other Tanium Core Platform components. To resolve the issue, reinstall the Tanium Client (see ).
Using TLS	This column indicates whether clients are (Yes) or are not (No) using Transport Layer Security (TLS) for communication with Tanium Cloud.
Send State	Normal: The client is sending data to its backward and forward peers. None: The client is not sending data to its forward or backward peers. Forward Only: The client is sending data to its forward peer but not to its backward peer. Backward Only: The client is sending data to its backward peer but not to its forward peer.
Receive State	Normal: The client is receiving data from its backward and forward peers. None: The client is not receiving data from its forward or backward peers. Next Only: The client is receiving data from its forward peer but not from its backward peer. Previous Only: The client is receiving data from its backward peer but not from its forward peer.
Status	Normal: The client is communicating normally. Slow Link: The client has connections with abnormally slow throughput. Leader: The client is communicating with Tanium Cloud because it is a backward leader, a forward leader, a neighborhood leader, or a client with no peer connections (such as a client in an isolated subnet). Blocked: The client is not communicating reliably.
Registration Error	(Salesforce deployments only) The client can be in one of the following registration states: None: Registration succeeded Failed Client Challenge: Registration failed because the client did not present the registration secret that is contained in the tanium-init.dat file. Failed Server Challenge: Registration failed because mismatching Tanium root keys prevented Tanium Cloud from establishing trust with the client or other Tanium Core Platform components. Root Key Mismatch: Registration failed due to any other issue related to mismatching Tanium root keys. Exceeded License Seats: Tanium Cloud denied registration for the client because the number of active clients exceeded the limit that the Tanium license specifies. Clients are considered active if they registered within the last two days. To resolve issues that relate to the Tanium root key or registration secret, re-install the Tanium Client on the affected endpoints. for a new Tanium license if you want to change the maximum number of active clients.
Last Registration	Date and time when the Tanium Client last registered with Tanium Cloud.
Protocol Version (hidden by default)	Tanium Protocol version. For details about the protocol, see TLS communication.
Version	Tanium Client version.

The Direction column displays icons that use the following conventions to depict Tanium Client connection states:

An up arrow indicates a connection with Tanium Cloud.
Side arrows pointing away from the client indicate outbound connections to peers.
Side arrows pointing at the client indicate inbound connections from peers.
Side arrows on the right side of clients indicate the state of connections to forward peers.
Side arrows on the left side of clients indicate the state of connections to backward peers.
Side arrows with dashed lines indicate slow connections.

You can use the Direction column to understand why a Tanium Client is a leader and to identify connection issues. The following table lists the possible connection states:

Table 3: Tanium Client peer connection states
Attribute	Value	Description
Leader	Backward	The client is a backward leader that terminates one end of a linear chain. It typically has the lowest IP address in its linear chain.
	Forward	The client is a forward leader that terminates one end of a linear chain. It typically has the highest IP address in its linear chain.
	Neighborhood	The client is designated as a neighborhood leader because its linear chain has reached the maximum number of clients.
	Isolated	The client is an isolated leader that connects only to Tanium Cloud, and has no connections to other clients. The client might be isolated because its IP address falls within the range of an isolated subnet or because it has no peers in its local subnet with which to connect.
Neighbor	No side arrows	This is the same as an isolated leader.
	Single side arrow or	The client has a neighborhood list of peers but has not established a peer connection. This state generally results from a misconfiguration, such as when a host-based firewall on the endpoint does not allow inbound connections to the client.
	Double side arrows	The client has a neighborhood list of peers and has connected with peers in the indicated direction.
Client state	Normal	The client is communicating normally.
Client state	Blocked	The client is not communicating reliably. This might result from a network issue or host resource issue, such as an anti-virus program that slows the client.

Export Tanium Client status details

Export information in the Client Status page as a CSV file or, if you have the Admin reserved role, as a JSON file.

From the Main menu, go to Administration > Configuration > Client Status.
Select rows in the grid to export information for specific Tanium Clients. If you want to export information for all clients, skip this step.
Click Export .
(Optional) Edit the default export File Name.
The file suffix (.csv or .json) changes automatically based on the Format selection.
Select an Export Data option: information for All clients in the grid or only for the Selected clients.
Select the file Format: JSON (Admin reserved role only) or CSV.
Click Export.
Tanium Cloud exports the file to the downloads folder on the system that you used to access the Tanium Console.

Copy Tanium Client status details

Copy information from the Client Status page to your clipboard to paste the information into a message, text file, or spreadsheet. Each row in the grid is a comma-separated value string.

From the Main menu, go to Administration > Configuration > Client Status.
Perform one of the following steps:
- Copy row information: Select one or more rows and click Copy .
- Copy cell information: Hover over the cell, click Options , and click Copy .

Deploy actions to remediate client registration or connectivity issues

You can deploy actions to Tanium Clients to remediate issues that you observe in the Client Status page.

From the Main menu, go to Administration > Configuration > Client Status.
Select the Tanium Clients (up to 100) to which you want to deploy actions and click Deploy Action.
Deploy the action.
Review the Client Status grid to verify that the action produced the expected result.

Customize listening ports

The client uses the listening port to receive communications from peer clients that are in the same linear chain. By default, the client listens for communication from peer clients on the port specified for the ServerPort setting, which is always 17472 for Tanium Cloud. You can configure a specific custom listening port, or you can randomize the listening port at intervals.

Work with your network administrator to configure your endpoint firewalls to allow incoming connections on any port that the Tanium Client uses to process requests. The process is TaniumClient.exe on Windows endpoints and TaniumClient or taniumclient on other endpoints.

If you configure listening port settings, use the same values for all clients in the same subnet.
Configure listening port settings when you deploy the Tanium Client. When deploying Tanium Client 7.4 or later, you can use the Tanium Server REST API to create a custom tanium-init.dat file that includes the necessary settings. See the Tanium Server REST API Reference for information about creating the PKI initialization bundle. If necessary, contact Tanium Support for access to that document. For other methods, see Deploying the Tanium Client using an installer or package file.

If you need to configure new custom listening port settings for existing clients, use a package. Make sure to deploy the package to all clients. See Packages.

Configure a custom listening port

To configure a specific custom listening port for client communication, configure the ListenPort setting on all clients. When you configure a value for the ListenPort setting, it overrides the ServerPort setting for communication between clients.

If you enable EnableRandomListeningPort, do not configure ListenPort because the client overwrites the value whenever it selects a new port.
Changes to ListenPort automatically affect the Tanium Client API port, which is one port number higher. For example, if you set ListenPort to 17473, the client API port becomes 17474.

Randomize listening ports

You can configure the Tanium Client to randomly select a new listening port at intervals.

Randomize listening ports only if it is required by rules in your organization. Using randomized listening ports requires more complex firewall rules to allow client communication, and it makes troubleshooting issues with client communication more difficult.

The following client settings on the control randomization of the listening port:

EnableRandomListeningPort

Enables (1) or disables (0) the randomized selection of a new listening port at intervals. The client uses the port for communication from peer clients. If another application is already using the selected port, the client selects another port immediately instead of at the next interval.

If you change EnableRandomListeningPort from enabled to disabled, you must also remove the ListenPort setting or set it to the desired port. Otherwise, the port that the client last randomly selected before you disabled EnableRandomListeningPort becomes the permanent listening port.

RandomListeningPortMin

Specifies the low end of the range of ports from which the client randomly selects a listening port if you enabled EnableRandomListeningPort. The default is port 32000.

RandomListeningPortMax

Specifies the high end of the range of ports from which the client randomly selects a listening port if you enabled EnableRandomListeningPort. The default is port 64000

RandomListeningPortTTLInHours

Specifies the interval in hours at which the client selects a new listening port if you enabled EnableRandomListeningPort. The default is 24 hours. Do not set the value lower than the client reset interval, which by default is a random interval in the range of 2 to 6 hours.

RandomListeningPortExclusions

Specifies ports that the client never selects as a listening port if you enable EnableRandomListeningPort. For example, to prevent port competition conflicts, you might specify ports that other applications use. If you specify multiple exclusions, use a comma to separate each port. By default, the client does not exclude any ports that are within the range that the RandomListeningPortMin and RandomListeningPortMax settings define.