Rift and Portal

Introduction

VeilNet Conflux supports two optional modes that change how traffic is routed:

• Rift mode — Behaves like a full-tunnel VPN: the default route in that network namespace is replaced by the VeilNet TUN interface, so all traffic from that namespace goes through VeilNet. Use case: air-gapped systems where you want every packet to egress via VeilNet.
• Portal mode — Conflux scans locally reachable networks and advertises them to other trusted nodes, acting as a mini SD-WAN. Other nodes can use this Conflux as a gateway to reach those networks. Use case: linking environments (e.g. multi-region Kubernetes, hybrid clouds).

You can enable rift, portal, both, or neither when registering a Conflux (CLI, system service, Docker, or Kubernetes).

Rift mode (full-tunnel)

In rift mode, the Conflux replaces the default route in its network namespace with the VeilNet TUN device. All traffic from that namespace is sent through VeilNet instead of the host’s normal default gateway.

Typical use: Air-gapped or locked-down systems where you want a single egress path (VeilNet) for all traffic so it can be inspected, filtered, or routed on the VeilNet side.

Caveats:

• Only enable in a dedicated network namespace (e.g. a container or VM). Do not enable rift on the host’s main namespace unless you intend to route the whole machine through VeilNet.
• In Kubernetes, run Conflux in a sidecar with a shared network namespace; enabling rift there affects only that pod.

Enabling rift mode

CLI (system service):

sudo veilnet-conflux register \
  -t "$VEILNET_REGISTRATION_TOKEN" \
  --tag "airgap-gateway" \
  --rift

Environment variable (systemd / Docker / Kubernetes):

VEILNET_CONFLUX_RIFT=true

Portal mode (mini SD-WAN)

In portal mode, Conflux discovers networks reachable from the local host (e.g. LANs, VPC subnets) and advertises them to other trusted Conflux nodes. Those nodes can then send traffic to this Conflux to reach those networks—effectively using it as a small SD-WAN edge.

Typical use: Linking environments without a full mesh or VPN: multi-region Kubernetes clusters, hybrid cloud, or connecting branch networks so workloads in one region can reach private IPs in another via VeilNet identity and routing.

Caveats:

• The Conflux host must have routes (or layer-2 access) to the networks you want to expose. Conflux scans and advertises what is reachable from that host.
• Only other Conflux nodes in the same registration context (and with compatible taints, if used) can use this node as a portal.

Enabling portal mode

CLI (system service):

sudo veilnet-conflux register \
  -t "$VEILNET_REGISTRATION_TOKEN" \
  --tag "region-us-east" \
  --portal

Environment variable (systemd / Docker / Kubernetes):

VEILNET_CONFLUX_PORTAL=true

Using both modes

You can enable rift and portal on the same Conflux (e.g. full-tunnel egress plus advertising local networks). Use both flags or both environment variables.

Example (CLI):

sudo veilnet-conflux register \
  -t "$VEILNET_REGISTRATION_TOKEN" \
  --tag "edge-node" \
  --rift \
  --portal

Example (Docker .env):

VEILNET_CONFLUX_RIFT=true
VEILNET_CONFLUX_PORTAL=true

Checking mode at runtime

After registration, you can confirm rift and portal state with:

veilnet-conflux info conflux

The output includes Rift and Portal (and other fields such as ID, Tag, UID, CIDR, Public).

Summary

Reference: System Service — register for full CLI and env options; Docker and K3s for container and Kubernetes examples.