Ingress and egress model

Nanami routing is modeled as explicit policy objects, not hidden runtime behavior.

Core terms

• Ingress device: the preferred entry point for traffic entering overlay flows.
• Egress device: the preferred exit point for traffic leaving overlay flows.
• Traffic mode:
  • vpn_only: overlay traffic for private resources only.
  • full_tunnel: force all traffic through selected egress.
• Routing mode:
  • auto: platform chooses ingress/egress.
  • manual: operator pins ingress and egress devices.

Policy layers

Routing intent can be set at multiple levels.

Priority (highest first):

1. Device routing preference
2. User routing preference
3. Network routing policy
4. System defaults

Diagram (text)

Network policy -> User preference -> Device preference -> Final selected ingress/egress

Validation rules

For manual selection, ingress and egress devices must:

• belong to the same tenant,
• belong to the target network,
• pass access checks for the acting user.

This prevents cross-tenant and cross-network misrouting.

Manual WireGuard configs (Limited Mode)

• Manual config files are user-editable and treated as untrusted input.
• Client-side AllowedIPs in manual config are not a security boundary.
• Nanami enforces isolation on gateways server-side:
  • strict peer identity AllowedIPs (/32 overlay IP),
  • deny-by-default forwarding ACL,
  • tenant-scoped route/assignment validation.

API surfaces

• GET/PUT /api/v1/networks/:id/routing-policy
• GET/PUT /api/v1/devices/:id/routing-preference

These endpoints expose the routing model even when UI workflows are still evolving.

Relation to node roles

Node roles (ingress_gateway, exit_gateway) describe capability and intent. Routing policies decide when and where those roles are used for a specific flow.

Current status

• Data model and API primitives are available.
• Broader policy UX and templates are still coming soon.
• Multi-hop chains (gateway -> gateway -> exit) are planned and not yet implemented.