Routing Policies

Routing Policies define traffic classification and routing rules that control how traffic is forwarded across your network. Policies can be scoped as global templates, edge-specific deployments, or device group access policies.

Navigate to Network > Policy Templates in the sidebar.

Overview

Stat Cards

Card	Description
Templates	Global policy templates (excludes DG-scoped policies)
Access Policies	Device group access policies and DG access templates combined
Active	Policies currently enabled
Total Rules	Sum of rules across all template policies
Edge Deployments	Number of policies applied (cloned) to specific edges

Policies Table

The table shows policy templates (policies without an edge assignment, excluding applied DGAPs). Each row displays:

Column	Description
Policy Name	Name with a scope badge: Template (blue), DG Template (indigo), Access Policy (purple), or Edge (green)
Priority	Numeric priority, color-coded: red (below 50), yellow (50--99), green (100+)
Rules	Number of rules in the policy
Edge Uses	How many edges have a copy of this template applied
Status	Enabled or Disabled
Actions	View Details, Edit, Delete

Policy Scopes

Scope	Label	Description
global	Template	Reusable routing policy blueprint. Can be applied (cloned) to specific edges for deployment.
edge	Edge	A policy applied to a specific edge. Created by cloning a global template to an edge. Not directly created by users.
dg_template	DG Access Template	A reusable access policy blueprint for device groups. Rules use placeholder destinations that are mapped to real subnets when applied.
device_group	Access Policy	An applied DG access policy, created by applying a DG template to a specific device group. Linked back to the source template via source_template_id.

When creating a new policy, you can choose between:

• Global Template -- for network routing policies applied to edges
• Device Group Access Template -- for access control policies applied to device groups

note

Scope cannot be changed after creation. The edge and device_group scopes are created automatically via template application, not directly.

Creating a Policy

1. Click New Policy.
2. Fill in the policy form:

Field	Required	Description
Policy Scope	Yes	Global Template or Device Group Access Template
Policy Name	Yes	Descriptive name (e.g., "VoIP Priority Routing")
Description	No	Purpose of this routing policy
Priority	Yes	Numeric priority 1--1000 (lower = higher precedence)
Status	Yes	Enabled or Disabled
Default Action	DG only	Deny (Zero Trust, recommended) or Allow. Controls what happens to unmatched traffic
Inspection Mode	Global only	Auto, Fast Path (L3/L4 only), or Full Inspection (via Suricata)

3. Click Create Policy to save.

Default Action (DG Access Policies)

For device group scoped policies, the default action determines the security posture:

Default Action	Behavior
Deny (Zero Trust)	All traffic blocked unless explicitly allowed by a rule. Add allow rules to whitelist destinations. Recommended.
Allow	All traffic permitted. Add drop or rate_limit rules to restrict specific destinations.

Inspection Mode (Global Templates)

Mode	Description
Auto	Rules are auto-classified based on match criteria (recommended)
Fast Path (Pre-Inspection)	Bypasses Suricata for maximum performance. L3/L4 matching only.
Full Inspection (Post-Inspection)	Forces all traffic through Suricata IDS/IPS inspection

note

DG access policies are always forced to pre_inspection (L3/L4 only) since they operate at the network layer without Suricata integration.

Policy Rules

Each rule within a policy defines matching criteria and an action. Rules are evaluated in order (by rule_order), and the first match wins.

Match Criteria

Rules can match traffic by:

Criterion	Description
Match Traffic By	Choose from: Any Traffic, Application, or Application Group
Application	Select a specific application definition (protocol + ports). DG policies are limited to L3/L4 apps (port/IP-based); domain-based apps are hidden.
Application Group	Select a group of applications (matched by any member)
Destination Subnet	CIDR notation (e.g., 192.168.1.0/24) or a smart picker (see below)
Time Window	Optional schedule restricting when the rule is active

Smart Destination Picker

When a rule is being edited for an edge-bound policy (not a global template), the destination subnet field shows a categorized dropdown populated from the edge's actual network configuration:

Category	Contents
WAN Interfaces	Subnets on WAN-facing ports
LAN Interfaces	Subnets on LAN-facing ports
E2E Peering	Learned routes from peering peers. Includes peer:* (all peering learned routes) sentinel.
Static Routes	Manually configured routes on the edge
Connectors	Subnets reachable via connectors
Special	Internet/default route (0.0.0.0/0)

You can also switch to Custom CIDR mode for manual entry.

For global templates (no edge context), the destination field shows "Set when applied to Edge" and is configured during template application.

tip

The peer:* sentinel value expands at batch-build time to include all learned routes from E2E peering peers. Use this when you want a rule to dynamically cover all peering destinations.

Action Types

Global / Edge Policies

Action	Description	Requires Target
Route via Interface	Forward traffic out a specific physical port (e.g., G0, G1)	Yes -- interface dropdown
Route via Next Hop	Forward traffic to a specific IPv4 gateway address	Yes -- IPv4 address
Route via Tunnel	Forward traffic through a VPN tunnel (wg0, wg1, wg2, host-xfrm-apps)	Yes -- tunnel dropdown
Drop	Silently discard matching traffic	No
Rate Limit	Throttle matching traffic to a bandwidth cap	Bandwidth (Mbps) required
Load Balance (ECMP)	Distribute traffic across multiple interfaces with weights	Interface list required

The tunnel dropdown includes:

• Tunnels: wg0 (IoT/Connector), wg1 (App VPN WireGuard), host-xfrm-apps (IKEv2 App VPN), wg2 (E2E Peering)
• Peering Peers: Individual peers listed under "Peering Peers" -- selecting a peer automatically switches the action to Route via Next Hop with the peer's tunnel IP

DG Access Policies

Action	Description
Allow	Permits traffic to the destination (only available when default action is Deny)
Drop	Blocks traffic to the destination
Rate Limit	Throttles traffic to the destination at a specified bandwidth

Additional Rule Options

Time Window Scheduling

Restrict when a rule is active by configuring:

1. Active Days: Select specific days (Mon--Sun), or use quick buttons: Weekdays, All Days, Clear
2. Start Time / End Time: 24-hour time range (e.g., 09:00 to 17:00)

The resulting schedule is stored as a string like Mon,Tue,Wed,Thu,Fri 09:00-17:00. Rules without a time window apply at all times.

DSCP Match / Mark

Field	Description
DSCP Match	Match packets with a specific DSCP value in the IP TOS field
DSCP Mark	Stamp outgoing packets with a DSCP value (requires Suricata service chain)

note

VPP's ACL plugin cannot match DSCP natively. DSCP-match rules use VPP classifier tables instead of ACL+ABF.

Rate Limiting

When action type is Rate Limit:

Field	Required	Description
Bandwidth Limit	Yes	Maximum throughput in Mbps

Rate limiting is implemented using VPP policer binapi with PolicerAdd / PolicerInput calls on the edge.

Load Balancing (ECMP)

When action type is Load Balance:

1. Add at least 2 interfaces using the Add Interface button
2. For each interface, select a physical port and assign a weight (1--255)
3. Choose the algorithm:

Algorithm	Description
Weighted	Distribute traffic proportionally based on interface weights

note

Load balancing uses SetIPFlowHash which operates per-VRF, not per-route. If multiple LB policies specify different algorithms, the last applied policy wins.

QoS Profile (Global Policies)

Profile	Description
Realtime	Lowest latency treatment
Priority	High priority queuing
Best Effort	Normal forwarding (default)

Fallback Target

An optional secondary interface or tunnel to use if the primary action target is unavailable. Selectable from the same interface/tunnel lists as the primary target.

ABF Priority Mapping

On the edge, routing policies are implemented using VPP Access-list Based Forwarding (ABF). The API priority (1--1000) maps to VPP ABF priority (20--99) via mapToABFPriority():

Component	ABF Priority
Tunnel Protection (ESP, WG, IKE)	8
Dynamic Path Selection (DPS)	15
User Routing Policies	20--99
Suricata IDS/IPS	100

Lower priority numbers are evaluated first. Ensure your most specific policies have the lowest API priority values.

View Details

Click the policy name or the View (gear) button to open a read-only detail modal showing all rules, their matching criteria, and actions.

Validate

Click the Validate button to check a policy for configuration errors. Validation returns warnings and errors as toast notifications.

Deployment to Edges

Routing policies are deployed to edges through the batch configuration system:

1. Global templates are cloned to a specific edge, creating an edge-scoped copy with real interface/subnet values.
2. DG access policies are automatically included in the batch for edges that have device groups with enabled policies.
3. The batch sync pushes all enabled policies to the edge agent, which translates them into VPP ACLs + ABF rules.

Changes to policies mark affected edges as dirty (config pending). The next batch sync deploys the updated configuration.

DG Policies on Edge Config Page

Edge configuration pages include a read-only Device Group Policies section that shows all DG access policies affecting that edge. Each rule displays a reachable flag indicating whether the destination subnet is accessible from the edge's current network configuration.

Edit and Delete

• Edit -- Opens the policy form with current values pre-filled. Scope cannot be changed.
• Delete -- Removes the policy after confirmation. For DG access policies, deletion also cleans up junction table entries and propagates dirty flags to affected edges.

warning

Deleting a policy that is applied to edges does not immediately remove it from those edges. The edge retains the old configuration until the next batch sync.