Skip to main content

Groups, Policies, and Routes Overview

This document provides an overview of the new groups, policies, and routes architecture in the WireGuard network management system.

What's New

The system has been redesigned with a modern, flexible architecture:

Groups

Organize peers into logical collections. Groups serve as the attachment point for policies and routes.

Key Features:

  • Admin-only management
  • Peers can belong to multiple groups
  • Non-destructive operations (deleting a group doesn't delete peers)

Learn More: Groups Management Guide

Policies

Define iptables rules applied on jump peers for traffic filtering. Policies are attached to groups.

Key Features:

  • Support input/output direction
  • Support allow/deny actions
  • Target by CIDR, peer, or group
  • Built-in templates for common patterns

Learn More: User Guide - Policies

Routes

Define external network destinations accessible through jump peers. Routes are added to WireGuard AllowedIPs.

Key Features:

  • Specify destination CIDR and jump peer
  • Attach to groups for automatic configuration
  • Support custom DNS domain suffixes

Learn More: User Guide - Routes

DNS Mappings

Provide name resolution for IP addresses within route networks.

Key Features:

  • Associate names with IPs in route CIDRs
  • FQDN format: name.route.domain
  • Propagate to jump peer DNS servers

Learn More: User Guide - DNS

Default Groups

Automatically assign groups to peers created by non-administrator users.

Key Features:

  • Admin-only configuration
  • Applied only to non-admin created peers
  • Useful for baseline policies

Learn More: User Guide - Default Groups

Getting Started

  1. Read the User Guide introduction
  2. Follow the Common Workflows
  3. Explore the API Reference

Architecture

┌─────────────────────────────────────────────────────────────┐
│ Network │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Groups │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ Group 1 │ │ Group 2 │ │ Group 3 │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ Peers: 3 │ │ Peers: 5 │ │ Peers: 2 │ │ │
│ │ │ Policies: 2 │ │ Policies: 1 │ │ Policies: 3 │ │ │
│ │ │ Routes: 1 │ │ Routes: 2 │ │ Routes: 0 │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Policies │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ Policy 1 │ │ Policy 2 │ │ Policy 3 │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ Rules: 3 │ │ Rules: 2 │ │ Rules: 5 │ │ │
│ │ │ Groups: 2 │ │ Groups: 1 │ │ Groups: 1 │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Routes │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ Route 1 │ │ Route 2 │ │ Route 3 │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ CIDR: /16 │ │ CIDR: /24 │ │ CIDR: /8 │ │ │
│ │ │ Jump: peer-1 │ │ Jump: peer-1 │ │ Jump: peer-2 │ │ │
│ │ │ DNS: 3 │ │ DNS: 1 │ │ DNS: 0 │ │ │
│ │ │ Groups: 2 │ │ Groups: 1 │ │ Groups: 1 │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘

Common Use Cases

1. Organize by Department

Create groups for each department and apply appropriate policies and routes.

Example: Engineering, Sales, Support groups with different access levels.

Guide: User Guide - Workflow 1

2. Multi-Tier Application Security

Set up web, app, and database tiers with controlled communication.

Example: Web tier can access app tier, app tier can access database tier.

Guide: User Guide - Workflow 4

3. Cloud Resource Access

Provide access to cloud networks (AWS, Azure, GCP) through jump peers.

Example: Route to AWS VPC with DNS resolution for internal services.

Guide: User Guide - Workflow 3

4. Incident Response

Quickly isolate compromised peers by moving them to a quarantine group.

Example: Move suspicious peer to isolated group with deny-all policy.

Guide: User Guide - Workflow 2

5. Default User Access

Configure baseline access for all non-admin created peers.

Example: All users get access to office network and internet by default.

Guide: User Guide - Default Groups

API Overview

Groups Endpoints

POST   /api/v1/networks/:networkId/groups
GET /api/v1/networks/:networkId/groups
GET /api/v1/networks/:networkId/groups/:groupId
PUT /api/v1/networks/:networkId/groups/:groupId
DELETE /api/v1/networks/:networkId/groups/:groupId
POST /api/v1/networks/:networkId/groups/:groupId/peers/:peerId
DELETE /api/v1/networks/:networkId/groups/:groupId/peers/:peerId

Policies Endpoints

POST   /api/v1/networks/:networkId/policies
GET /api/v1/networks/:networkId/policies
GET /api/v1/networks/:networkId/policies/:policyId
PUT /api/v1/networks/:networkId/policies/:policyId
DELETE /api/v1/networks/:networkId/policies/:policyId
POST /api/v1/networks/:networkId/policies/:policyId/rules
DELETE /api/v1/networks/:networkId/policies/:policyId/rules/:ruleId
GET /api/v1/networks/:networkId/policies/templates
POST /api/v1/networks/:networkId/groups/:groupId/policies/:policyId
DELETE /api/v1/networks/:networkId/groups/:groupId/policies/:policyId
GET /api/v1/networks/:networkId/groups/:groupId/policies

Routes Endpoints

POST   /api/v1/networks/:networkId/routes
GET /api/v1/networks/:networkId/routes
GET /api/v1/networks/:networkId/routes/:routeId
PUT /api/v1/networks/:networkId/routes/:routeId
DELETE /api/v1/networks/:networkId/routes/:routeId
POST /api/v1/networks/:networkId/groups/:groupId/routes/:routeId
DELETE /api/v1/networks/:networkId/groups/:groupId/routes/:routeId
GET /api/v1/networks/:networkId/groups/:groupId/routes

DNS Endpoints

POST   /api/v1/networks/:networkId/routes/:routeId/dns
GET /api/v1/networks/:networkId/routes/:routeId/dns
PUT /api/v1/networks/:networkId/routes/:routeId/dns/:dnsId
DELETE /api/v1/networks/:networkId/routes/:routeId/dns/:dnsId
GET /api/v1/networks/:networkId/dns

Full Details: API Reference

Security Considerations

Admin-Only Operations

All group, policy, route, and DNS operations require administrator privileges.

Authorization

  • Non-admin users receive HTTP 403 for admin operations
  • Authorization checked at both API and service layers

Audit Logging

All administrative operations are logged for security auditing.

Default Deny

Traffic is denied by default unless explicitly allowed by policies.

Principle of Least Privilege

Start with minimal access and add permissions as needed.

Performance Considerations

Scalability

  • Groups: Thousands per network
  • Policies: Hundreds per network
  • Routes: Hundreds per network
  • Peers per group: Thousands

Configuration Updates

  • Policy changes: Applied within seconds via WebSocket
  • Route changes: WireGuard configs regenerated automatically
  • DNS changes: Propagated to jump peers within 60 seconds

Database Optimization

  • Indexed foreign keys for fast lookups
  • Connection pooling for concurrent requests
  • Batch operations for bulk changes

Troubleshooting

Quick Diagnostics

Check group membership:

curl -H "Authorization: Bearer $TOKEN" \
"$API_URL/networks/$NETWORK_ID/groups/$GROUP_ID"

Check attached policies:

curl -H "Authorization: Bearer $TOKEN" \
"$API_URL/networks/$NETWORK_ID/groups/$GROUP_ID/policies"

Check attached routes:

curl -H "Authorization: Bearer $TOKEN" \
"$API_URL/networks/$NETWORK_ID/groups/$GROUP_ID/routes"

Check iptables on jump peer:

iptables -L -n -v

Check WireGuard config:

wg show

Full Guide: See the Troubleshooting page in the sidebar.

Support

Documentation

Getting Help

  1. Check documentation and troubleshooting guides
  2. Review server logs: docker logs wireguard-server
  3. Check agent logs: journalctl -u wireguard-agent
  4. Open GitHub issue with details