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:

  1. Review the policy configuration
  2. Select the distribution channel: Canary (limited rollout) or Stable (full rollout)
  3. Click Publish
  4. The policy is signed with the control plane's policy signing key
  5. Confirm the publication

Published policies appear in the policy list with version number, publication timestamp, and channel.

Rollback

If a policy causes issues:

  1. Navigate to the policy list
  2. Find the previous version
  3. Click Rollback to this version
  4. 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

  1. Navigate to Gateway Pools
  2. Click Create Pool
  3. 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

  1. Navigate to Enrollment Tokens
  2. Click Generate Token
  3. 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:

  1. Click Batch Generate
  2. Set count (1-100), target tenant, and auto-creation settings
  3. Optionally provide an email distribution list (one email per line)
  4. 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.