Skip to content

joshfinley/frontnet

Repository files navigation

FrontNet

FrontNet is a multi-layer, multi-label traffic redirection framework designed to handle arbitrary network traffic.

How it works

FrontNet uses label switching on one or more nodes to redirect traffic. Protocol layer support is loosely aligned with the OSI model, where layer-based forwarder services are defined in crates/fn-forwarder for layer types. Currently, FrontNet offers the strongest support for layer 4 and layer 7 (via Pingora). Limited support for L2 and L3 also exists.

When configured with multiple nodes, a FrontNet network may include edge nodes, bridge nodes, and relay nodes. Edge nodes face the internet and take in traffic with user defined origin policies. Bridge nodes sit between edges and backends, applying labels and forwarding. Relay nodes support NAT traversal by establishing a tunnel to remote edge nodes.

The label-switching protocol resembles MPLS with stackable label envelopes. FrontNet's traffic labeling is designed to minimize label overhead while avoiding the limitations of the traditional MPLS label format and to avoid coupling with external sources of authority like BGP. An ingress edge applies a small label onto each packet, governed by routes set for the applicable node. The label and a return label travel in a 64-bit frame prepended to the payload. The egress reads the return label from the packet and needs no return-table lookup. All of this travels over QUIC, which gives every link TLS 1.3 and connection migration.

FrontNet separates policy and data using a plane model.

  • The network plane carries traffic.
  • The management plane carries policy

Policy items include access control, rate limits, redirection rules, and the routes themselves.

+-------------------------------------------------------------+
|                                                             |
|   +-----------------------------------------------------+   |
|   |                   NETWORK PLANE                     |   |
|   |         (components, nodes, routes, tunnels)        |   |
|   +----------------------------+------------------------+   |
|                                |                            |
|   +----------------------------+------------------------+   |
|   |                  MANAGEMENT PLANE                   |   |
|   |      (ACL, rate limit, redirection, L3-L7 routing)  |   |
|   |        Northbound Policy, Southbound Policy         |   |
|   +-----------------------------------------------------+   |
|                                                             |
+-------------------------------------------------------------+

The wire formats, the routing protocol, the transport, and the security model are specified in DESIGN.txt.

FrontNet also includes an experimental design for external points-of-presence (pops). Ingress and egress pops allow for translation and forwarding of traffic in sitauations where full FrontNet nodes can't be deployed. This allows for establishing edges in various environments. Any host or runtime environment that supports sending data over the internet could be used to bridge that environment into a FrontNet network.

Repository layout

A Cargo workspace with three crate families:

  • crates/fn-* — the node and data plane: core types, the forwarder (L3/L4/L7), DID identity, the node runtime, the event bus, and the RPC framing.
  • crates/fm-* — the management plane: the manager, provider adapters (DigitalOcean, AWS), and observability.
  • crates/fc-* — clients: the fc-ctl CLI and the fc-web operator dashboard.

The workspace also includes several examples (examples/) covering most features.

Build

cargo xt check          # build, clippy, and test (the CI gate)
cargo build --release   # release binaries

Building the fc-web dashboard (cargo xt ui) needs two extra tools: the wasm32-unknown-unknown target for the argon2 key-derivation module and esbuild on PATH for the TypeScript/CSS bundle.

rustup target add wasm32-unknown-unknown

cargo build works without these: the fc-web crate writes a placeholder page when the UI has not been built, so the workspace always compiles. Run cargo xt ui to produce the real dashboard assets.

Run

The example topology runs a manager with an edge, relay, and egress on one machine:

./examples/dev.sh       # generate keys, build, and start the topology

dev.sh calls examples/setup-keys.sh to generate identity keys and patch the example TOML configs. Note that the frontend web application requires client certificate authentication (Chromium recommended).

To build and run only the manager against examples/manager.toml:

cargo xt dev

Talk to a running node with the control client:

cargo run -p ctrl-client -- examples/keys/ctrl.key 127.0.0.1:9009

Other tasks:

cargo xt ui             # build the fc-web dashboard
cargo xt bundle         # cross-compile release bundles for deployment

examples/REMOTE-EDGE.md walks through running an edge on a remote VPS that tunnels back through a local network.

Documentation