Boundaries

Boundaries are the guardrails change requests are checked against. Each one describes a kind of firewall rule and says whether requests for it pass, fail, or need review. This page covers writing one, how matching works, and the grid views. Concepts has the overview.

Boundaries are created, opened, and edited by Administrators and Connect Boundary Authors. Project Managers, Readonly Users, and Firewall Change Approvers can see the Boundaries list. See Users and Roles.

The Boundaries page

Boundaries in the navigation menu opens the table view, one row per Boundary (or per statement, for a Boundary imported with several): whether it's Enforced (the switch is live, so you can enable or disable a Boundary without opening it), its Result, name, project, the request type it applies to, whether it's bidirectional, its sources, destinations, and services, which fields it requires, and who changed it last.

View switches between Boundaries (the table), Grid, and Groups; see Grid views. The buttons above the table create a new Boundary, refresh the list, and import or export Boundaries as JSON.

Creating a Boundary

Click New Boundary. The form has two parts.

Boundary details

Field	What it does
Name	Shown in change request results and in the requester's summary.
Project	The project the Boundary belongs to.
Result	Pass, Fail, or Score & Review. A Score & Review Boundary also takes a Score from 0 to 100.
Enforced	Off keeps the Boundary but leaves it out of every evaluation. Useful while drafting.
Target(s)	Accounts to export matching requests to when the Boundary's result is Pass or Score & Review: your Guardicore and ServiceNow accounts. See Guardicore and ServiceNow.
Message	Text shown to the requester when a request matches this Boundary. Explain what to change or whom to contact.

The statement

The statement describes the requests the Boundary applies to. A request rule matches when every part of the statement matches it; a part left empty matches anything.

Part	What it matches
Request Type	Allow rules, Deny rules, or Either.
Bidirectional	Also match with the request's source and destination swapped.
Source and Destination	Network objects: Any (the firewall's any object, which matches only a request that also uses any), a CIDR or single address, a Group, or an Inventory Item. A CIDR, Group, or Inventory Item carries a comparison, Contain (the Boundary's addresses include the request's) or Equal (they're the same), and Does or Does Not to negate it; Any is used as it is. Several objects on one side are alternatives: matching any one of them is sufficient.
Host Limit	A minimum and maximum number of hosts the request's side may cover, added up across its objects. any counts as unlimited.
Service	Any (matches only a request for all traffic), All TCP, All UDP, All ICMPv4, All ICMPv6, a TCP or UDP port range, an ICMPv4 or ICMPv6 type and code, or a Custom Protocol number. A port range matches a request whose ports fall inside it; an All entry matches the corresponding all-ports request and any single range of that protocol.
Port Limit	A minimum and maximum number of ports the request's services may cover in total, counting TCP and UDP only; an all-ports entry counts as 65,536.
Required	Select Comment, Expiration, Justification, or Owner to match only requests that leave that field blank. Combined with a Fail result, this rejects requests that don't say why.

A Boundary with an empty statement matches every request, which is one way to define a catch-all.

Matching rules

The details that decide borderline cases:

• Matching is per rule. A request with several rules matches a Boundary if any one of its rules does, and the result shows which rules matched.
• Contain is the default comparison. A Boundary source of 10.0.0.0/8 matches a request source of 10.1.2.0/24, and a request source that's a Group whose addresses all fall inside 10.0.0.0/8. Equal requires the same addresses on both sides.
• Groups and inventory items are resolved when the request is evaluated, so a Boundary written against a Group follows the Group's membership. A Boundary Group and a request Group with the same ID match without comparing addresses.
• any is special. A Boundary object of any matches only a request that uses any. A Boundary CIDR or Group never matches a request any, unless the object is negated (Does Not), in which case any counts as outside it.
• Bidirectional is tried only after the straight comparison fails: the Boundary's destinations are compared with the request's sources, and its sources with the request's destinations.
• Only enforced Boundaries count, and validation errors in the request (a missing name, an invalid CIDR) fail it regardless of Boundaries.

The verdict combines every matching Boundary: any Fail fails the request; otherwise any Pass passes it; otherwise the request takes the default result (Review, unless you've changed it under Settings > Boundaries), carrying the highest matching score. Evaluation results shows what the requester sees.

The default result

When no Boundary matches a request at all, the request goes to Review. Settings > Boundaries changes that: choose Pass to let unmatched requests through, or Fail to reject anything you haven't explicitly allowed. Reset to default returns to Review. The setting applies to evaluations from then on; requests already evaluated aren't re-run.

Grid views

The Grid view lays Boundaries out as a matrix: one row per source and one column per destination, drawn from every Boundary's statement, enforced or not. Each cell covers requests from that source to that destination and is colored by the results of the Boundaries that match it. A split cell means Boundaries with different results both apply, and the number is how many. The Legend button explains the colors. Hover a cell to list its Boundaries, or to create a Boundary for that source and destination with both already filled in. The buttons above the grid add a CIDR, Group, or inventory item as a row and column, so you can create Boundaries for objects nothing references yet.

The Groups view is the same matrix restricted to Groups: pick the Groups to show, and each cell lists the Boundaries that name one as source and the other as destination. It counts the Boundaries that name both Groups directly.

Import and export

Export downloads one Boundary (from its row) or all of them (from the button above the table) as JSON. Import takes a JSON file containing one Boundary or a list of them and creates them in the project you choose. Importing a file exported from the same organization updates the Boundaries it contains. Together they let you copy Boundaries between organizations or keep them in version control.