Configuring Tanium Client subnets

Separated subnets, intentional subnets, and isolated subnets provide methods for modifying the default peering behavior of Tanium Clients. Default peering settings define the boundaries of client subnetworks (subnets) in the Tanium™ linear chain architecture. Before configuring subnets, be sure that you understand the behavior that the default settings define and the impact of your changes. See Tanium Client Management User Guide: Configuring Tanium Client peering.

For the permissions to view and manage the Tanium Client subnet configurations, see Configure Tanium Client subnets.

To troubleshoot client peering issues, see Troubleshoot Tanium Client issues.

Review the client subnet configurations on a monthly basis to account for any subnets that are added to or removed from your network. See Tanium Maintenance User Guide: Review and update Tanium Client subnets.

In Tanium Core Platform 7.4.3 or later, Tanium Servers write subnet configurations to the Tanium database and automatically synchronize them in an active-active deployment. In Tanium Core Platform 7.4.6 or later, the subnet configurations in the database are also synchronized among Tanium Zone Servers. In most environments, the separated and isolated subnets configurations are the same for all Zone Servers and Tanium Servers. In complex environments with overlapping subnets, you might have to segregate subnets differently for Zone Servers. In such cases, you can add SeparatedSubnets.txt and IsolatedSubnets.txt files to the Zone Servers to override the synchronized database configurations. Intentional subnets configurations are always synchronized across all Zone Servers and Tanium Servers.

The following figure illustrates a deployment with where internal Tanium Clients connect with Tanium Servers in an active-active deployment and external clients connect with the Zone Server. This example shows separated subnets, intentional subnets, and isolated subnets within the linear chains that the default peering settings define.

The following figure shows the Tanium database on a dedicated host in a Windows deployment. However, in a Tanium Appliance deployment, the database is on the same host as the Tanium Servers.

Figure  1:  Tanium Client peering (click image to enlarge)

Configure separated subnets

Tanium Clients in a separated subnet can peer only with other clients that are within that subnet. Configure separated subnets to specify more granular exceptions for Tanium Client peering than the default /24 subnet boundaries that the address mask or prefix settings define (see Tanium Client Management User Guide: Address mask and prefix settings). Clients use the separated subnets configuration for peering based on whether they connect to the Tanium Server or Zone Server. Each server uses the configuration to manage the peer lists for clients that register through it. After you configure separated subnets, you do not have to restart the servers.

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. To verify that the separated subnets work as expected after the clients register, see Tanium Client Management User Guide: Verify Tanium Client peering and leader connections.

Tanium Core Platform 7.3 or later supports IPv6 subnets, such as: 2001:db8::/32. Contact Tanium Support for details.

Configure separated subnets that are the same for Tanium Servers and Zone Servers

Add subnets

  1. From the Main menu, go to Administration > Configuration > Subnets.
  2. In the Separated Subnets section, click New Subnets.
  3. 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.
    2001:db8::/32

    If your deployment includes Zone Servers that require different separated subnets than the Tanium Servers, copy entries from the text field to the clipboard to use when you configure separated subnets that are specific to Zone Servers.

  4. Click Save.

Edit subnets

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

Configure separated subnets that are specific to Zone Servers

If a deployment includes Zone Servers that require different separated subnets than the Tanium Servers, perform the following steps based on your Tanium infrastructure to add a custom separated subnets configuration to each server. Because Zone Servers do not synchronize custom subnet configurations, each server can have a unique configuration.

Windows infrastructure

  1. Create a plain text file named SeparatedSubnets.txt.
  2. Enter the subnets and optional comments that you entered for the Tanium Server into SeparatedSubnets.txt. Use the formatting described in Add subnets.
  3. Move SeparatedSubnets.txt to the installation directory of each Zone Server (the default installation directory is \Program Files (x86)\Tanium\Tanium Zone Server). If necessary, you can modify the file contents for each Zone Server that requires a unique configuration.

If you remove SeparatedSubnets.txt from the Zone Server, it reverts to using the separated subnets that are configured on the Tanium Servers.

Tanium Appliance infrastructure

  1. On the Zone Server appliance, sign in to the TanOS console as a user with the tanadmin role.
  2. From the tanadmin menu, enter 2 to go to the Tanium Operations menu. ClosedView screen
  3. Enter 2 to go to the Configuration Settings menu. ClosedView screen
  4. Enter 12 to edit the SeparatedSubnets.txt file. ClosedView screen
  5. Use the menu to specify subnets in CIDR format.

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 the Tanium Server or Zone Server sends that client an empty peer list to prevent the client from participating in peering.

After you configure isolated subnets, you do not have to restart the Tanium Servers or Zone Servers. Tanium Clients take two to six hours (the randomized client-reset interval) to finish applying all the changes associated with the new configuration. To verify that the isolated subnets work as expected after the clients register, see Tanium Client Management User Guide: Verify Tanium Client peering and leader connections.

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.

Tanium Core Platform 7.3 or later supports IPv6 subnets, such as: 2001:db8::/32. Contact Tanium Support for details.

Configure isolated subnets that are the same for Tanium Servers and Zone Servers

Add subnets

  1. From the Main menu, go to Administration > Configuration > Subnets.
  2. In the Isolated Subnets section, click New Subnets.
  3. 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.
    2001:db8::/32

    If your deployment includes Zone Servers that require different isolated subnets than the Tanium Servers, copy entries from the text field to the clipboard to use when you configure isolated subnets that are specific to Zone Servers.

  4. Click Save.

Edit subnets

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

Configure isolated subnets that are specific to Zone Servers

If a deployment includes Zone Servers that require different isolated subnets than the Tanium Servers, perform one of the following procedures based on your Tanium infrastructure and whether you want to isolate all clients or clients on specific subnets. Because Zone Servers do not synchronize custom subnet configurations, each server can have a unique configuration.

The Zone Server applies the most restrictive rule to determine the subnet for a client. If you configure the zs_address_mask or AddressMask setting to isolate clients, that setting overrides any subnet-based isolation that is configured in an IsolatedSubnets.txt file.

Isolate all clients connected to any Zone Server

Set the zs_address_mask platform setting on the Tanium Server (Administration > Configuration > Settings > Advanced Settings) to 4294967295, which specifies /32 subnet boundaries (single hosts) for all Zone Servers.

For more information, see Tanium Client Management User Guide: Address mask and prefix settings.

Isolate all clients connected to a particular Zone Server

  1. Sign in to the Zone Server host as an administrator user.
  2. Access the CLI (see Tanium Core Platform Deployment Reference Guide: Command-line interface).

  3. Navigate to the Zone Server installation folder:

    > cd <Zone Server>

  4. Configure the AddressMask local setting to specify /32 subnet boundaries (single hosts):

    > TaniumZoneServer config set AddressMask 4294967295

For more information, see Tanium Client Management User Guide: Address mask and prefix settings.

Isolate clients on specific subnets with Windows infrastructure

  1. Create a plain text file named IsolatedSubnets.txt.
  2. Enter the subnets and optional comments that you entered for the Tanium Server into IsolatedSubnets.txt. Use the formatting described in Add subnets.
  3. Move IsolatedSubnets.txt to the installation directory of each Zone Server (the default installation directory is \Program Files (x86)\Tanium\Tanium Zone Server). If necessary, you can modify the file contents for each Zone Server that requires a unique configuration.

If you remove IsolatedSubnets.txt from the Zone Server, it reverts to using the isolated subnets that are configured on the Tanium Servers.

Isolate clients on specific subnets with Tanium Appliance infrastructure

  1. On the Zone Server appliance, sign in to the TanOS console as a user with the tanadmin role.
  2. From the tanadmin menu, enter 2 to go to the Tanium Operations menu. ClosedView screen
  3. Enter 2 to go to the Configuration Settings menu. ClosedView screen
  4. Enter 11 to edit the IsolatedSubnets.txt file. ClosedView screen
  5. Use the menu to specify subnets in CIDR format.

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 Cloudthe Tanium Server or Tanium Zone Server. 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 Cloudthe server. 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 Cloudthe server over the Internet.

Intentional subnets require Tanium Core Platform 7.5.3 or later and Tanium Client 7.4.7.1130 or later. Using the PeerNeighborhood client setting requires Tanium Core Platform 7.5.5 or later.

You can configure IPv6 subnets, such as: 2001:db8::/32. Contact Tanium Support for details.

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 Tanium Client Management User Guide: Overview of Tanium Client peering settings).

 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 Cloudthe Tanium Server 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:

  1. 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 The Tanium Server considers pre-NAT IP addresses to be in the same subnet based on the AddressMask (IPv4) or AddressPrefixIPv6 setting.

  2. 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.

  3. 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.

  4. 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.

Intentional subnet configurations are always synchronized across all Zone Servers and Tanium Servers.

Define intentional subnets using Sites

Tanium Cloud The Tanium Server 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
  1. From the Main menu, go to Administration > Configuration > Subnets.
  2. In the Intentional Subnets section, click New Subnets.
  3. Enter a name to identify the Site that comprises the intentional subnets.
  4. (Optional) Enter a comment to help other users understand the function of the subnet in your organization.
  5. In the New subnet CIDRs field, enter each subnet in CIDR format (a.b.c.d/x) using separate lines or commas as delimiters.
  6. Click Save.
Edit subnets
  1. From the Main menu, go to Administration > Configuration > Subnets.
  2. Select one of the Intentional Subnets and click Edit.
  3. 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 CloudThe Tanium Server allows these clients to peer, regardless of the NAT IP of each client.

Using the PeerNeighborhood client setting to define intentional subnets requires Tanium Core Platform 7.5.5 or later.

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 Tanium Client Management User Guide: Modify client settings.

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 Verify or remediate Tanium Client peering and leader connections. 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.