Ingress and egress path selection

title: Ingress and egress path selection description: How Nanami models gateway selection and traffic steering without implying app publishing.

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

This page is about path selection and traffic steering. It is not the contract for reverse proxying browser/API surfaces, and it does not imply arbitrary service publishing through custom domains, paths, or ports.

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 workspace,
• belong to the target network,
• pass access checks for the acting user.

This prevents cross-workspace 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,
  • workspace-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.
• Service publishing with custom domains, paths, and ports is not part of the current shipped product contract.
• Multi-hop chains (gateway -> gateway -> exit) are planned and not yet implemented.