99d8fcb8fc
## Description We want to resolve DNS queries of type SRV & TXT for DNS resources within the network context of the site that is hosting the DNS resource itself. This allows admins to e.g. deploy dedicated nameservers into those sites and have them resolve their SRV and TXT records to names that are scoped to that particular site. SRV records themselves return more domains which - if they are configured as DNS resources - will be intercepted and then routed to the correct site. Prior to this PR, SRV & TXT records got resolved by the DNS server configured on the client (or the server defined in the Firezone portal), even if the domain in question was a DNS resource. This effectively meant that those SRV records have to be valid globally and could not be specific to the site that the DNS resource is hosted in. ## Example Say we have these wildcard DNS resources: - `**.department-a.example.com` - `**.department-b.example.com` Each of these DNS resources is assigned to a different site. If we now issue an SRV DNS query to `_my-service.department-a.example.com`, we may receive back the following records: - `_my-service.department-a.example.com. 86400 IN SRV 10 60 8080 my-service1.department-a.example.com.` - `_my-service.department-a.example.com. 86400 IN SRV 10 60 8080 my-service2.department-a.example.com.` - `_my-service.department-a.example.com. 86400 IN SRV 10 60 8080 my-service3.department-a.example.com.` Notice how the SRV records point to domains that will also match the wildcard DNS resource above! If that is the case, Firezone will also intercept A & AAAA queries for this service (which are a natural follow-up from an application making an SRV query). As a result, traffic for `my-service1.department-a.example.com` will be routed to the same site the DNS resource is defined in. If the returned domains don't match the wildcard DNS resource, the traffic will either not be intercepted at all (if it is not a DNS resource) or routed to whichever site defines the corresponding DNS resource. All of these scenarios may be what the admin wants. If the SRV records defined for the DNS resource are globally valid (and e.g. not even resources), then resolving them using the Client's system resolver may be all that is needed. If the services are running in a dedicated site, that traffic should indeed be routed to that site. As such, Firezone itself cannot make any assumption about the structure of these records at all. The only thing that is enabled with this PR is that IF the structure happens to match the same DNS resource, it allows admins to deploy site-specific services that resolve their concrete domains via SRV records. ## Testing The implementation is tested using our property-based testing framework. In order to cover these cases, we introduce the notion of site-specific DNS records which are sampled when we create each individual Gateway. When selecting a domain to query for, all global DNS records and the site-specific ones are merged and a domain name and query type is chosen at random. At present, this testing framework does not assert that the DNS response itself is correct, i.e. that it actually returned the site-specific record. We don't assert this for any other DNS queries, hence this is left for a future extension. We do assert using our regression grep's that we hit the codepath of querying an SRV or TXT record for a DNS resource. Related: #8221
A modern alternative to legacy VPNs.
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/headless-client: Cross-platform 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/google-cloud/nat-gateway: Example Terraform configuration for deploying a cluster of Firezone Gateways behind a NAT gateway on GCP with a single egress IP.
- terraform/modules/google-cloud/apps/gateway-region-instance-group: Production-ready Terraform module for deploying regional Firezone Gateways to Google Cloud Compute using Regional Instance Groups.
Quickstart
The quickest way to get started with Firezone is to sign up for an account at https://app.firezone.dev/sign_up.
Once you've signed up, follow the instructions in the welcome email to get started.
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 our internal APIs are changing rapidly so we can't meaningfully support self-hosting Firezone in production at this time.
If you're feeling especially adventurous and want to self-host Firezone for educational or hobby purposes, follow the instructions to spin up a local development environment in CONTRIBUTING.md.
The latest published clients (on App Stores and on
releases) are only guaranteed
to work with the managed version of Firezone and may not work with a self-hosted
portal built from this repository. This is because Apple and Google can
sometimes delay updates to their app stores, and so the latest published version
may not be compatible with the tip of main from this repository.
Therefore, if you're experimenting with self-hosting Firezone, you will probably want to use clients you build and distribute yourself as well.
See the READMEs in the following directories for more information on building each client:
- macOS / iOS: swift/apple
- Android / ChromeOS: kotlin/android
- Windows / Linux: rust/gui-client
How long will 0.7 be supported until?
Firezone 0.7 is currently end-of-life and has stopped receiving updates as of
January 31st, 2024. It will continue to be available indefinitely from the
legacy branch of this repo under the Apache 2.0 license.
How much does it cost?
We offer flexible per-seat monthly and annual plans for the cloud-managed version of Firezone, with optional invoicing for larger organizations. See our pricing page for more details.
Those experimenting with self-hosting can use Firezone for free without feature or seat limitations, but we can't provide support for self-hosted installations at this time.
Documentation
Additional documentation on general usage, troubleshooting, and configuration can be found at https://www.firezone.dev/kb.
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.
- Join our Discord Server: Join live discussions, meet other users, and chat with the Firezone team.
- Open a PR: Contribute a bugfix or make a contribution to Firezone.
If you need help deploying or maintaining Firezone for your business, consider contacting our sales team to speak with a Firezone expert.
See all support options on our main support page.
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.