mirror of https://github.com/outbackdingo/firezone.git synced 2026-01-27 10:18:54 +00:00

Files

Thomas Eizinger 90d10a8634 refactor(connlib): improve fairness of event-loop (#10347 )

The event-loop inside `Tunnel` processes input according to a certain
priority. We only take input from lower priority sources when the higher
priority sources are not ready. The current priorities are:

- Flush all buffers
- Read from UDP sockets
- Read from TUN device
- Read from DNS servers
- Process recursive DNS queries
- Check timeout

The idea of this priority ordering is to keep all kinds of processing
bounded and "finish" any kind of work that is on-going before taking on
new work. Anything that sits in a buffer is basically done with
processing and just needs to be written out to the network / device.
Arriving UDP packets have already traversed the network and been
encrypted on the other end, meaning they are higher priority than
reading from the TUN device. Packets from the TUN device still need to
be encrypted and sent to the remote.

Whilst there is merit in this design, it also bears the potential of
starving input sources further down if the top ones are extremely busy.
To prevent this, we refactor `Io` to read from all input sources and
present it to the event-loop as a batch, allowing all sources to make
progress before looping around. Since this event-loop has first been
conceived, we have refactored `Io` to use background threads for the UDP
sockets and TUN device, meaning they will make progress by themselves
anyway until the channels to the main-thread fill up. As such, there
shouldn't be any latency increase in processing packets even though we
are performing slightly more work per event-loop tick.

This kind of batch-processing highlights a problem: Bailing out with an
error midway through processing a batch leaves the remainder of the
batch unprocessed, essentially dropping packets. To fix this, we
introduce a new `TunnelError` type that presents a collection of errors
that we encountered while processing the batch. This might actually also
be a problem with what is currently in `main` because we are already
batch-processing packets there but possibly are bailing out midway
through the batch.

---------

Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Mariusz Klochowicz <mariusz@klochowicz.com>

2025-09-17 23:28:36 +00:00

src

refactor(connlib): improve fairness of event-loop (#10347 )

2025-09-17 23:28:36 +00:00

Cargo.toml

chore: publish gateway 1.4.16 (#10321 )

2025-09-10 04:50:43 +00:00

README.md

fix(docs): use sha256sum over sha256 (#9690 )

2025-06-27 20:08:41 +00:00

README.md

gateway

This crate houses the Firezone gateway.

Building

You can build the gateway using: cargo build --release --bin firezone-gateway

You should then find a binary in target/release/firezone-gateway.

Running

The Firezone Gateway supports Linux only. To run the Gateway binary on your Linux host:

Generate a new Gateway token from the "Gateways" section of the admin portal and save it in your secrets manager.
Ensure the FIREZONE_TOKEN=<gateway_token> environment variable is set securely in your Gateway's shell environment. The Gateway requires this variable at startup.
Set FIREZONE_ID to a unique string to identify this gateway in the portal, e.g. export FIREZONE_ID=$(head -c 32 /dev/urandom | sha256sum | cut -d' ' -f1). The Gateway requires this variable at startup. We recommend this to be a 64 character hex string.
Now, you can start the Gateway with:

firezone-gateway

If you're running as a non-root user, you'll need the CAP_NET_ADMIN capability to open /dev/net/tun. You can add this to the gateway binary with:

sudo setcap 'cap_net_admin+eip' /path/to/firezone-gateway

Ports

The gateway requires no open ports. Connections automatically traverse NAT with STUN/TURN via the relay.