Skip to main content

Rules Engine

What is the Rules Engine?​

The ZeroTier Rules Engine is a distributed traffic control system that runs inside the ZeroTier agent on each device. It allows you to define network access policies through ZeroTier Central that are then enforced locally and bidirectionally on every node.

Why Does It Matter?​

Traditional firewalls and endpoint security tools only see encrypted ZeroTier traffic - they can't inspect or control what happens inside your virtual network. The rules engine operates at the ZeroTier virtual network layer, giving you granular control over traffic between specific devices or groups.

The rules engine is distributed and cryptographically secured. Policies are configured centrally through ZeroTier Central, then signed and pushed to each node where they're enforced locally. To bypass these rules, an attacker would need to compromise both sides of a connection.

note

The rules engine works alongside traditional security tools like firewalls and endpoint protection. They can and should be used together for full control over your network environment.

Traffic on ZeroTier networks can be observed and controlled with a system of globally applied network rules. These are enforced in a distributed fashion by both the senders and the receivers of packets. To escape the rules engine, a malicious attacker would need to fully compromise both sides of any conversation.

Rules in New Central​

New Central provides a streamlined interface for managing network flow rules. To configure rules for your network, navigate to the Networks page and select the Flow Rules tab.

Flow Rules Tab

Rule Types​

Non-IP L2 Protocol Filter​

Each network includes a default Non-IP L2 Protocol Filter that allows only IPv4, IPv6, and ARP traffic, blocking all other Ethernet frame types. This filter operates at the data link layer and provides basic protocol whitelisting for your network.

Non-IP L2 Protocol Filter

Isolation Rules​

Isolation rules allow you to block all network traffic except for specific ports and protocols. This is useful for implementing least-privilege access policies and network segmentation. Isolation rules are evaluated in order, and traffic that doesn't match any isolation rule will be blocked by default when isolation mode is enabled.

Isolation Rules

Besides the default isolation rules based on the most common use-cases, custom port/protocols are also possible. For instance, to serve only a gaming server on TCP/UDP 25565:

Custom Port Configuration

Managing Rules​

Enabling and Disabling Rules​

To enable or disable any rule:

  1. Navigate to your network's Rules tab
  2. Click the toggle button next to the rule you want to enable or disable
  3. Click Save to apply your changes

Disable Rule

note

Disabling the Non-IP L2 Protocol Filter is not typically recommended, as it allows all Ethernet frame types on your network. If you attempt to disable it, an additional warning will be displayed.

Toggle Rule Warning

Adding Flow Rules​

To add a new isolation rule:

  1. Navigate to your network's Rules tab
  2. Click Add Flow Rule
  3. Define your Rule
  4. Optional: Add Excluded Devices
  5. Click Save

Add Flow Rule

Deleting Rules​

To delete an isolation rule:

  1. Navigate to your network's Rules tab
  2. Click the trashcan icon next to the rule you want to delete
  3. Click Save to apply your changes

Delete Rule

Resetting Rules​

To reset all rules to their defaults (disabling all custom rules except the Non-IP L2 Protocol Filter):

  1. Navigate to your network's Rules tab
  2. Click the Restore Defaults button
  3. Click Save to confirm
info

Resetting rules disables all custom isolation rules but does not delete them. You can re-enable rules individually after resetting.

Example: Webserver Network with Selective SSH Exclusion​

In this example, we're designing a network with layered access control. We'll create two complementary rules that work together to provide different levels of access to different devices.

Step 1: Create the base network rule​

First, we'll limit most network traffic to ICMP (for diagnostics) and HTTPS. This allows all authorized users to access a hosted webserver while maintaining basic network troubleshooting capabilities through ping and traceroute.

Besides the default protocols like HTTPS, custom protocol/port combinations are also available.

Add Flow Rule Button

Step 2: Exclude devices that need additional access​

We can exclude specific devices from this rule. These devices aren't exempt from all rules on the network, just from this particular one. In this case, we want the Webserver (which hosts the HTTPS site) and the primary Workstation to be able to communicate using SSH for administrative access, so we'll exclude them from this rule.

Exclude Devices

Once configured, click Save to apply the rule.

Save Rule

Step 3: Create a rule for excluded devices​

Now we'll create a second rule specifically for the devices we excluded above. This rule will allow the Webserver and Workstation to communicate with each other using ICMP, HTTPS, and SSH.

Add Second Flow Rule

Note that we must include ICMP and HTTPS exceptions in this rule as well. Without them, this rule would block ICMP and HTTPS traffic for the excluded devices, since our first rule no longer applies to them. Each device is subject to the rules that apply to it - exclusions from one rule don't automatically grant access; you must explicitly allow the traffic in another rule.

Complete Multi-Rule Setup

This creates a layered access control model where:

  • Most devices can use ICMP and HTTPS
  • Webserver and Workstation can use ICMP, HTTPS, and SSH with each other

The diagram below illustrates this multi-rule network architecture:

Multi-Rule Network Architecture

This pattern enables a pseudo-hub-and-spoke architecture where most devices (spokes) can only access specific central resources, while administrative devices (hub) have broader access. This approach is useful for scenarios like:

  • Client devices accessing a central server but not each other
  • Remote workers accessing company resources without lateral movement
  • IoT devices communicating with a gateway but remaining isolated from each other.