Tunnels & tunnel chaining
Tunnel chaining links multiple nodes into a forwarding path: client → A → B → landing. Each hop is FF1 Core on a node, relaying traffic upstream hop by hop.
Client → Node A (ingress) → Node B (transit) → Target (landing)Building a chain
Section titled “Building a chain”On the tunnels page, chain the nodes in order; the path points to each previous hop via upstream_tunnel_id. The ingress node exposes the external port, while the rest are only visible within the chain.
Change one hop, sync the whole chain
Section titled “Change one hop, sync the whole chain”This is the key to tunnel chaining: change any link in the chain and the Master re-delivers config to every node in the chain, not just the ingress node. This avoids a broken chain caused by a middle hop whose config was not updated. Track change progress in the config delivery queue.
Common uses
Section titled “Common uses”- Ingress on a premium-route region, landing at the target data center, with a transit in between to optimize routing
- Multi-hop jump servers to hide the landing IP