d092e22840
I ended up calling it `reconnect` because that is really what we are doing: - We reconnect to the portal. - We "reconnect" to all relays, i.e. refresh the allocations. I decided **not** to use an ICE restart. An ICE restart clears the local as well as the remote credentials, meaning we would need to run another instance of the signalling protocol. The current control plane does not support this and it is also unnecessary in our situation. In the case of an actual network change (e.g. WiFI to cellular), refreshing of the allocations will turn up new candidates as that is how we discovered our original ones in the first place. Because we constantly operate in ICE trickle mode, those will be sent to the remote via the control plane and we start testing them. As those new paths become available, str0m will automatically nominate them in case the current one runs into an ICE timeout. Here is a screen-recording of the Linux CLI client where `Session::refresh` is triggered via the SIGHUP signal: [Screencast from 2024-03-14 11-16-47.webm](https://github.com/firezone/firezone/assets/5486389/7171d199-f2a2-4b22-92c8-243494d5d6d8) Provides the infrastructure for: #4028.
A modern alternative to legacy VPNs.
Note: 🚧 The main branch is undergoing major restructuring in preparation
for the release of Firezone 1.0 🚧.
See the legacy branch if
you're looking for Firezone 0.7.
Read the 1.0 announcement for more.
Overview
Firezone is an open source platform to securely manage remote access for any-sized organization. Unlike most VPNs, Firezone takes a granular, least-privileged approach to access management with group-based policies that control access to individual applications, entire subnets, and everything in between.
Features
Firezone is:
- Fast: Built on WireGuard® to be 3-4 times faster than OpenVPN.
- Scalable: Deploy two or more gateways for automatic load balancing and failover.
- Private: Peer-to-peer, end-to-end encrypted tunnels prevent packets from routing through our infrastructure.
- Secure: Zero attack surface thanks to Firezone's holepunching tech which establishes tunnels on-the-fly at the time of access.
- Open: Our entire product is open-source, allowing anyone to audit the codebase.
- Flexible: Authenticate users via email, Google Workspace, Okta, Entra ID, or OIDC and sync users and groups automatically.
- Simple: Deploy gateways and configure access in minutes with a snappy admin UI.
Firezone is not:
- A tool for creating bi-directional mesh networks
- A full-featured router or firewall
- An IPSec or OpenVPN server
Contents of this repository
This is a monorepo containing the full Firezone product, marketing website, and product documentation, organized as follows:
- elixir: Control plane and internal Elixir libraries:
- elixir/apps/web: Admin UI
- elixir/apps/api: API for Clients, Relays and Gateways.
- rust/: Data plane and internal Rust libraries:
- rust/gateway: Gateway - Tunnel server based on WireGuard and deployed to your infrastructure.
- rust/relay: Relay - STUN/TURN server to facilitate holepunching.
- rust/linux-client: Linux CLI client.
- rust/gui-client: Cross-platform GUI client.
- swift/: macOS / iOS clients.
- kotlin/: Android / ChromeOS clients.
- website/: Marketing website and product documentation.
- terraform/: Terraform files for various example deployments.
- terraform/examples/gcp/nat_gateway: Example Terraform configurations for deploying a cluster of Firezone gateways behind a NAT gateway on GCP with single egress IP.
- terraform/modules/gateway-google-cloud-compute: Production-ready Terraform module for deploying regional Firezone gateways to Google Cloud Compute.
Quickstart
Firezone 1.x is currently accepting early access signups for closed testing. Fill out the early access form to request access and we'll be in touch!
Frequently asked questions (FAQ)
Can I self-host Firezone?
Our license won't stop you from self-hosting the entire Firezone product top to bottom, but we can't commit the resources to make this a smooth experience and therefore don't support self-hosting the control plane at this time.
If you have a business case requiring an on-prem installation of Firezone please get in touch.
If you're feeling especially adventurous and want to self-host Firezone for educational or recreational purposes, you'll want to build and distribute the clients from source to ensure they remain locked to a version compatible with your self-hosted control plane. Unfortunately, the following clients must be distributed through proprietary app stores due to restrictions imposed by Apple and Google:
- macOS
- iOS
- Android / ChromeOS
Because it's impossible to select which client version to install from a particular app store, building and distributing Firezone from source is the only to way self-host Firezone at this time.
Otherwise, if you're hobbyist or developer and are looking to spin it up locally to contribute or experiment with, see CONTRIBUTING.md.
How do I upgrade from 0.7?
Unfortunately, you can't. The good news is Firezone 1.x is much easier to setup and manage than 0.x and so you probably don't need to.
How long will 0.7 be supported until?
Firezone 0.7 is currently end-of-life and will stop receiving updates after
January 31st, 2024. It will continue to be available indefinitely from the
legacy branch of this repo under the Apache 2.0 license.
What's your pricing structure like?
Please see our pricing page at https://www.firezone.dev/pricing?utm_source=readme
Documentation
Additional documentation on general usage, troubleshooting, and configuration can be found at https://docs.firezone.dev.
Get Help
If you're looking for help installing, configuring, or using Firezone, check our community support options:
- Discussion Forums: Ask questions, report bugs, and suggest features.
- Public Slack Group: Join live discussions, meet other users, and get to know the contributors.
- Open a PR: Contribute a bugfix or make a contribution to Firezone.
Star History
Developing and Contributing
See CONTRIBUTING.md.
Security
See SECURITY.md.
License
Portions of this software are licensed as follows:
- All content residing under the "elixir/" directory of this repository, if that directory exists, is licensed under the "Elastic License 2.0" license defined in "elixir/LICENSE".
- All third party components incorporated into the Firezone Software are licensed under the original license provided by the owner of the applicable component.
- Content outside of the above mentioned directories or restrictions above is available under the "Apache 2.0 License" license as defined in "LICENSE".
WireGuard® is a registered trademark of Jason A. Donenfeld.