Device Groups

Device Groups organize VPN app devices into edge-bound collections. Each group is tied to a specific edge (dedicated or MTGE), has its own IP subnet, and can have an access policy that controls what traffic group members are allowed to reach.

Navigate to Equipment > Device Groups in the sidebar.

Overview

Stat Cards

Card	Description
Total Groups	Number of device groups
Total Devices	Sum of all devices across all groups
Bound to Edges	Groups that have an edge assignment
With Policy	Groups that have a Device Group Access Policy applied

Table Columns

Column	Description
Group Name	Name and description of the group
Edge	Bound edge name and type badge (Edge or MTGE). Unbound groups show a warning
Subnet	Allocated subnet CIDR (e.g., 10.10.3.0/24)
Devices	Current device count vs. max capacity (color-coded: red >95%, amber >80%)
Access Policy	Linked DG Access Policy name and enabled/disabled indicator
Actions	Edit and Delete buttons

warning

Groups without an edge binding show an "Unbound" warning. A migration banner appears at the top of the page when unbound groups exist, prompting you to assign an edge.

Creating a Group

1. Click Create Group.
2. Fill in the form:

Field	Required	Description
Group Name	Yes	A descriptive name (e.g., "Engineering Team")
Description	No	Additional details about the group's purpose
Edge / Gateway	No	Select a dedicated edge or MTGE to bind this group to
Max Devices	No	Maximum number of devices (1--253, default 50). Limited by the /24 subnet

3. Click Create Group to save.

Edge Binding

Each device group can be bound to exactly one edge (1:1 relationship). The edge determines where devices in this group will connect for VPN access.

Edge Type	Badge	Description
Dedicated	Edge (blue)	A dedicated edge appliance running VPP
MTGE	MTGE (purple)	A multi-tenant gateway edge shared across tenants

The edge dropdown lists all non-decommissioned dedicated edges and all active/provisioned MTGEs assigned to your tenant. Each option shows the edge name and WAN IP.

tip

Selecting "No edge binding (legacy)" leaves the group unbound. This is only for backward compatibility. Bind your groups to edges to enable DG-based registration and access policies.

Subnet Allocation

When a device group is created, the server automatically allocates a /24 subnet from the 10.10.0.0/16 address space. Each group gets a unique third octet (e.g., 10.10.1.0/24, 10.10.2.0/24). Octet 3 = 0 (10.10.0.0/24) is reserved for ungrouped devices.

The /24 subnet size means a maximum of 253 usable device addresses per group. The Max Devices field enforces a capacity limit within that range.

Capacity Indicator

The Devices column shows current/max with color coding:

Color	Condition
Gray (normal)	Below 80% capacity
Amber	80--95% capacity
Red	Above 95% capacity

Editing a Group

Click the Edit button (or click the group name) to open the edit modal. You can modify:

• Group name and description
• Edge binding (change which edge the group connects to)
• Max devices limit
• Access policy (enable/disable, remove, or replace)

note

Changing the edge binding may require devices in the group to re-register with the new edge.

Deleting a Group

Click the Delete button on a group row. A confirmation dialog shows:

• The group name
• The number of devices currently assigned (if any)

If the group has devices, they are unassigned (not deleted) and lose their group-level access policies. The devices continue to function with their base VPN configuration.

Device Group Access Policies (DGAP)

A Device Group Access Policy controls what network resources members of the group can reach. Each group can have at most one access policy.

How Access Policies Work

Access policies are a specialized type of routing policy with scope device_group. They support three action types:

Action	Description
Allow	Permits traffic to the specified destination (used with Zero Trust / deny-by-default)
Drop	Blocks traffic to the specified destination
Rate Limit	Throttles traffic to the specified destination at a given bandwidth (Mbps)

Zero Trust (Default Deny)

When a DGAP has default_action = deny, all traffic from group members is blocked by default. You must add explicit allow rules for each permitted destination. This is the recommended approach for security-sensitive environments.

When default_action = allow, traffic flows freely and you add drop or rate_limit rules to restrict specific destinations.

Applying an Access Policy Template

Access policies are created from DG Access Templates (scope dg_template), which are reusable policy blueprints with placeholder destinations.

To apply a template:

1. Open the group edit modal.
2. In the Access Policy section, click Apply Access Policy Template.
3. Step 1: Select a template from the list. Each template shows its priority, rule count, and default action (Allow or Deny (Zero Trust)).
4. Step 2: Map each rule's destination to a real subnet from the edge's network. The dropdown is categorized by source:
   • WAN Interfaces -- subnets on WAN-facing ports
   • LAN Interfaces -- subnets on LAN-facing ports
   • E2E Peering -- learned routes from peering peers (includes "Any Peer" wildcard)
   • Static Routes -- manually configured routes
   • Connectors -- connector subnets
   • Special -- internet/default route (0.0.0.0/0)
5. Click Apply Template.

note

Applied policies start disabled. Enable the policy from the group edit modal when you are ready to enforce it.

Managing an Existing Policy

Once a policy is applied, the group edit modal shows:

• The policy name, enabled/disabled status, and rule count
• The source template name (if created from a template)
• Enable/Disable toggle to activate or deactivate enforcement
• Remove button to delete the policy from the group (requires confirmation)
• Replace with different template link to remove the current policy and apply a new one

warning

The group must be bound to an edge before you can apply an access policy template. The template application requires edge context to populate the destination subnet dropdown.

VPN User Registration

Device groups are mandatory during VPN user registration. When inviting VPN users, you must select at least one device group. The first group in the list becomes the user's primary group.

• Mandatory selection: The invite form requires deviceGroupIds[] (minimum 1).
• Primary group: The first entry determines the initial edge the user's device connects to.
• Multi-DG support: Users can be assigned to multiple groups and switch between them from the VPN app.
• Capacity check: Registration validates that the target group has not reached its max_devices limit.

Failover

If a group's edge goes offline for more than 5 minutes, the system can offer failover to an alternative group. The device_group_failovers table tracks failover relationships. The VPN app can call POST /switch-group to migrate to a different group, which triggers re-registration against the new edge.

Effect of Group Assignment

When a device is in a group:

• The device connects to the group's bound edge for VPN access
• The device receives an IP from the group's /24 subnet
• The group's access policy (if enabled) controls traffic routing
• Changes to the group's policy propagate to all devices and mark affected edges as dirty

When a device is removed from a group:

• The device loses its group-level access policy
• The device may need to re-register if the edge binding changes