Policy Configuration
AegisWire policies control how client devices connect, what traffic is tunnelled, which gateways are used, and what security posture is enforced. Policies are created in the admin interface, signed, and distributed to client devices via the control plane.
Policy Model
Policies in AegisWire are signed, versioned bundles that are distributed to client devices. When a policy is published, clients receive the update on their next refresh cycle (or immediately if connected).
Policy Scope
Policies can be scoped to:
- All tenants: A global default policy
- Specific tenant: Applies to all users in a tenant
- Specific group: Applies to all users in a group
- Specific device: Applies to a single enrolled device
When multiple policies apply, the most specific scope wins (device > group > tenant > global).
Creating a Policy
Navigate to Policies in the admin interface and click Create Policy.
Tunnel Mode
| Mode | Description |
|---|---|
| Full Tunnel | All traffic from the client routes through the AegisWire tunnel. This is the most secure option — nothing leaks outside the tunnel. |
| Split Tunnel | Only traffic matching configured routes goes through the tunnel. All other traffic uses the client's local internet connection. |
For split tunnel, configure routes as repeatable rows:
- CIDR: The destination network (e.g.,
10.0.0.0/8,192.168.1.0/24) - Protocol: TCP, UDP, or Any
- Port: Specific port or range (e.g.,
443,8000-9000) - Action: Allow (route through tunnel) or Deny (block)
Default Access
- Allow: Traffic not matching any rule is permitted (use with split tunnel)
- Deny: Traffic not matching any rule is blocked (zero-trust default)
Authentication Requirements
Configure the minimum authentication mode for connections under this policy:
| Mode | Description |
|---|---|
| Mode A | PSK / enrollment token authentication |
| Mode B | Certificate-based with classical signatures |
| Mode C | Certificate-based with post-quantum signature support |
| Mode D | TOFU / pinned static trust with policy guardrails |
| Mode E | Out-of-band provisioned trust binding |
| Mode F | AuthKEM / KEMTLS-style authentication |
The policy sets a minimum mode — clients must authenticate at or above this level. Downgrade to a weaker mode is never permitted.
DNS Configuration
- DNS through tunnel: All DNS queries route through the VPN tunnel (recommended)
- Enterprise DNS servers: Specify DNS servers that clients must use (e.g., your internal DNS)
- DNS filtering: Block resolution of specific domains or categories
- Split DNS: Route specific domains to specific DNS servers (e.g., internal domains to corporate DNS, everything else to public DNS)
Kill Switch
- Enabled: Block all network traffic if the VPN connection drops
- Mode: "Always on" blocks traffic whenever disconnected; "On disconnect" only blocks on unexpected drops
Anti-Fingerprinting Profile
For deployments where traffic obfuscation is important:
| Profile | Description |
|---|---|
| Low | GREASE randomization and basic deterministic padding |
| Medium | Enhanced padding profiles and moderate cover traffic |
| High | Aggressive padding, cover traffic, and adaptive shaping |
Higher profiles consume more bandwidth but reduce metadata leakage and fingerprinting surface.
PQ Re-Randomization
For long-lived sessions, configure how often fresh post-quantum key material is injected:
| Mode | Description |
|---|---|
| Off | No additional PQ contribution after initial handshake |
| Periodic | Fresh PQ material injected at regular intervals |
| Aggressive | Frequent PQ re-randomization for maximum forward secrecy |
Publishing a Policy
After creating a policy:
- Review the policy configuration
- Select the distribution channel: Canary (limited rollout) or Stable (full rollout)
- Click Publish
- The policy is signed with the control plane's policy signing key
- Confirm the publication
Published policies appear in the policy list with version number, publication timestamp, and channel.
Rollback
If a policy causes issues:
- Navigate to the policy list
- Find the previous version
- Click Rollback to this version
- The previous policy is re-published to all affected clients
Policy Refresh
Client devices check for policy updates:
- On every connection establishment
- Periodically while connected (configurable interval, default 15 minutes)
- On manual refresh triggered by the user
The policy refresh is lightweight — clients send their current policy version and the control plane responds with either "no change" or the updated policy bundle.
Gateway Pool Configuration
Gateway pools determine which gateways client devices can connect to.
Creating a Gateway Pool
- Navigate to Gateway Pools
- Click Create Pool
- Configure:
- Pool ID: Auto-generated or admin-specified
- Display name: Human-readable name
- Region: Geographic region for this pool
- Priority: Integer priority for gateway selection (lower = preferred)
- Auth mode: Which authentication mode this gateway pool supports
- Endpoints: One or more address:port pairs
Gateway Capabilities
Each gateway pool advertises its capabilities:
- Supported auth modes: Which authentication modes are available
- Privacy profiles: Which anti-fingerprinting profiles are supported
- Cover traffic profiles: Available cover traffic levels
- Camouflage profiles: Available outer encoding profiles
- Multipath mode: Off, standard, or high-assurance
- PQ re-randomization: Off, periodic, or aggressive
Clients use these capabilities to select a compatible gateway based on the active policy requirements.
Enrollment Token Management
Control device enrollment with tokens:
Generating Tokens
- Navigate to Enrollment Tokens
- Click Generate Token
- Configure:
- Target tenant: Which tenant the enrolled device belongs to
- Target user: Specific user or auto-create on enrollment
- Token type: Single-use (consumed after one enrollment) or time-limited
- Expiry: 1 to 720 hours
- Note: Admin-visible label for tracking
Batch Generation
For large deployments:
- Click Batch Generate
- Set count (1-100), target tenant, and auto-creation settings
- Optionally provide an email distribution list (one email per line)
- Tokens are generated and can be exported as CSV
Token Lifecycle
Tokens progress through states: Pending (issued, not yet used), Redeemed (used for enrollment), Expired (past expiry time), Revoked (manually revoked by admin).
Revoked or expired tokens cannot be used for enrollment.