Skip to main content

Connection Rules

Connection Rules define how machines are allowed to communicate with each other. In Block by Default mode, these rules form the foundation of zero-trust machine communications—only explicitly permitted connections are allowed.

Policy Overview

See Managing Policies for an overview of all policy types, their precedence, and when to use each type.

Overview​

Connection rules enable you to:

  • Define communication scope: Specify which machines can communicate, over which protocols, and whether the traffic is allowed or blocked.
  • Directional enforcement: Control source-to-destination communications
  • Scalable policy management: Manage thousands of machines through organized rules

Automatic Rule Discovery​

When Gatekeepers observe traffic between two imported machines, the Console automatically creates connection rules in a Pending state. This enables you to:

  • Discover existing communication patterns without manual rule creation
  • Review discovered connections before approving them
  • Convert Pending rules to Allow or Block rules based on your policy decisions

Pending rules appear in the Console but are not enforced until you explicitly approve them and set their action (Allow or Block).

Connection Rule Fundamentals​

Rule Components​

A connection rule specifies:

  • Source: The machine initiating the connection
  • Destination: The machine receiving the connection
  • Action: Allow or Block
  • Protocol/Port: Specific protocol or port restrictions

Directional Enforcement​

Connection rules are directional—they define source → destination communication:

  • Rule allowing Machine A → Machine B does not allow Machine B → Machine A
  • For enforcement on bidirectional communication, both directions of communication must be allowed or blocked

Enforcement Mode Interaction​

Connection rules interact with Gatekeeper enforcement modes:

In Allow by Default Mode​

  • Only Block connection rules are enforced
  • Allow connection rules are skipped
  • All traffic is permitted unless explicitly blocked

In Block by Default Mode​

  • Only Allow connection rules are enforced
  • Block connection rules are skipped
  • All traffic is blocked unless explicitly allowed

In Observe-Only Mode​

  • Connection rules are logged but not enforced
  • Use this mode to build policies before enforcement

Workflow for Setting Rules​

  1. Deploy Gatekeepers in Observe-Only mode for 2-4 weeks to discover connections
  2. Review Pending rules automatically created by the Console from observed traffic
  3. Approve and configure Pending rules by converting them to Allow or Block rules
  4. Test in Allow by Default mode to verify no unintended blocks
  5. Switch to Block by Default mode for zero-trust enforcement

Examples​

Connection rules are the building blocks for creating a secure, zero-trust network. Here are some common scenarios where they are applied:

1. Lock Down Legacy Protocols​

Allow an insecure protocol like FTP only for the single, specific workflow that requires it, while blocking it everywhere else.

  • Goal: Allow a specific PLC to upload data to a historian server using FTP.
  • Rule:
    • Source: PLC-01
    • Destination: historian-server-01
    • Action: Allowed
    • Protocol/Port: TCP/21
  • Result: Only the approved PLC-01 can use FTP. Any other machine attempting to use FTP will be blocked, mitigating the risk of the insecure protocol.

2. Restrict Administrative Access​

Ensure that administrative protocols like SSH are only accessible from designated management workstations or bastion hosts.

  • Goal: Ensure only an administrator's machine can use SSH to manage a specific server.
  • Rule:
    • Source: admin-workstation-davis
    • Destination: linux-server-01
    • Action: Allowed
    • Protocol/Port: TCP/22
  • Result: This prevents any other machine from attempting to SSH into the server, significantly reducing the attack surface.

3. Isolate Workstation from Database​

Create an explicit block rule to prevent any possibility of a specific workstation connecting to a database.

  • Goal: Explicitly block a workstation from connecting to a database.
  • Rule:
    • Source: workstation-smith
    • Destination: db-main
    • Action: Blocked
    • Protocol/Port: TCP/1433 (SQL Server)
  • Result: This rule provides a crucial safeguard against accidental connections or potential breaches. It is enforced even if the Gatekeeper is in "Allow by Default" mode.

Testing Connection Rules​

Before deploying rules in production:

  1. Observe connections: Run Gatekeepers in Observe-Only mode to discover traffic
  2. Review Connection Canvas: Visualize existing connections
  3. Verify in Allow by Default: Test rules in permissive mode first
  4. Monitor violations: Watch for blocked legitimate traffic
  5. Gradual rollout: Deploy rules in phases, monitoring after each change

Best Practices​

  1. Start with discovery: Use Observe-Only mode before initially setting policies to allowed or blocked
  2. Organize with groups: Microsegment your network with machine groups
  3. Use Connection Canvas: Visualize connections before setting policies to allowed or blocked
  4. Progressive hardening: Move through enforcement modes gradually
  5. Test in permissive mode: Verify rules in Allow by Default before switching to Block by Default
  6. Monitor after changes: View console to see if successful and failed requests reflect the intended network policy
  7. Regular audits: Periodically review rules to ensure they remain accurate

Troubleshooting​

  1. Check enforcement mode of the gatekeeper
  2. Verify the gatekeeper is healthy and syncing rules
  3. Review enforcement by protocol rules
  4. Verify connection rule is accurate
    • direction (source → destination)
    • port/protocol
    • status (allowed/blocked)

Next Steps​