Here’s a demo: https://youtu.be/QEv7dJwKMvo.
Historically, the tool used to achieve this has been the corporate VPN. These work off a security model where you authenticate with the perimeter and gain access to the network behind it, which works when most workers are in office and resources on-prem. But as workers go remote and resources move to the cloud, the perimeter blurs, making it harder to secure.
I experienced this issue first-hand as a security engineer hunting for APT malware on Cisco's intranet. Malware often landed first on remote employee laptops, then spread from there to critical internal systems. Firewalls were somewhat effective at solving this problem, but they were clunky—it could take months for Infosec to approve requests to allow your team’s app or services through.
When Covid forced everyone to work from home, even Cisco struggled to grapple with the increased demand on its VPN concentrators. The perimeter defense model meant that we had to VPN into the intranet to get anything done, and if the speeds were really bad, we couldn't work that day.
One way to solve the above problems is to break up the single perimeter into many smaller ones, shifting them closer to the resources they protect. That way, compromising one perimeter does not gain you access to all others, and traffic is not bottlenecked through a single choke point. However, now you have many VPN tunnels instead of one, and most VPN protocols are too heavyweight for this.
If Cisco was facing these issues with remote access, I thought, others must be facing similar problems. So when WireGuard came along, I started Firezone.
WireGuard tunnels are so lightweight you can open thousands of them from an iPhone to whatever resources you need access to. Firezone builds on that and also handles NAT traversal, so you don’t need to change your firewall configuration to use it. Just deploy Gateways - small, statically-linked Linux binaries - where you need access, and Firezone’s homegrown STUN/TURN layer (we call “snownet”) handles the rest. If you need more throughput, just deploy more Gateways, and load is balanced across all of them.
WireGuard keys are distributed to peers only when access to a particular resource is authorized, and private keys never leave the device’s memory where they were generated. If a Gateway goes offline, Firezone will migrate connections from it to healthy ones within about 10 seconds, without user intervention. We lean heavily on Elixir/Phoenix and OTP’s awesome concurrency features to power all of this.
Firezone’s access control system is intentionally very simple. Policies define which user groups have access to which resources based on a default-deny system. More perimeters means more rules managing access to them, so we intentionally wanted to keep admins out of “ACL hell” as the number of controls grew.
One area we’re actively working to improve is our UI/UX - Firezone is a product built by engineers, for engineers, and at times, it shows! Expect refinements to come in this area over the coming months.
I’d love for you to give Firezone a try! You can spin up a demo instance at https://app.firezone.dev/try without signing up, and download clients from https://www.firezone.dev/kb/client-apps. And if you’re curious to learn more about how Firezone works, see for yourself - we build in the open at https://www.github.com/firezone/firezone.
Thanks for reading, and I look forward to your feedback!
I'm curious how you guys are competing with the other folks in the space. WARP was/is a really tough product to maintain (crossplatform networking is very difficult). CF was doing well with WARP mostly due to the distribution advantage. I imagine it's harder for startups to break into the space.
I'm sure it wasn't the part of the product you worked on but the onboarding experience, wow, just terrible.
Are there many big installations of it? With the vast majority of stuff being written for regular networks I do wonder if the amount of proxies/sidecars becomes unreasonable. Probably not though
That's cool, I did that for an HTTP forwarding thing a while back.
We're trying to stay focused on keeping policies easy to define and manage so that access management is... manageable as you scale. That and the fact data doesn't go through the cloud / intermediary have been a couple of the reasons customers say they prefer us.
Definitely an exciting space to be building in!
It was before the refactoring and the move to zero trust, so back then it was a simple admin panel. It was maybe mid 2022 I implemented it.
There was a terraform module I created for setting up the basic infrastructure, but there is no way the module supports the current state of the product. I guess it moved way quicker than I was able to follow LOL. The module was accepted in the Firezone group but later discontinued, for obvious reasons. I wish I had the time to contribute to the project supporting an official module for it, but I guess life happens to everyone haha
Good luck with the project! This is really good and very needed, the only other alternative being Tailscale, which is all closed source.
Love that you are using rust!
"What works well for HN [demo video] is short and direct, with zero production values. Skip any introductions and jump straight into showing your product doing what it does best. It should take only a few seconds before we see it in action, doing something cool. Voiceover is good, but no marketing slickness—no fancy logos or background music or anything like that!"
I can see how maybe this could be counter-grain for some enterprise products.
I have tried to use Headscale with Tailscale clients and have been fairly successful in achieving a private P2P VPN. Since I have a lot of spare servers, was able to setup a GUI, Headscale server and configure Tailscale clients across different OS flavors. But it is not for the faint of heart or non-technical folks or for enterprise use. What I have implemented was for personal use and it has it's own pitfalls / troubleshooting stuff which actually consumed a lot of time and effort.
Is there an open source option with Firezone where I could try it out to have a head to head comparison (or if a comparison that already exists) or a guide that could be used for setting up one's own server and client apps for a self-hosted and self-managed solution using Firezone?
Please recommend / respond with the opinion of whether the thought process is worth it? Thanks.
We do have a self-hosted community support channel on Discord if you are feeling adventurous: https://discord.gg/DY8gxpSgep
I would recommend starting here with a local development cluster:
https://github.com/firezone/firezone/blob/main/docs/CONTRIBU...
Strong FOSS projects tend to have multiple options for commercial support. So, if a hostile company acquires your commercial support provider, looking at you Broadcom, you have some options to move to someone friendlier for support.
So, for my employer it is about having options.
Tailscale is building a remarkable moat at extraordinary pace: capabilities real commercial use needs, on pricing that doesn't penalize the security-minded startup.
One key difference with their platform is the recognition so often missed inside the HN bubble that most B2B and B2C are on M365 and Entra, not Google like 3 devs in a cafe. Tailscale seems to understand the difference, but rather than going "enterprise" brings the startup ways into the business context, letting a business be like a startup while still complying with "requirements" such as sound patterns for tying into legacy internal and third party systems and networks.
A related difference is emphasis on "everything as code" from config to policy, enabling gitops of course, but also easier integration and automation.
That said, Firezone's choice to let groups flow from IdP and map resources to groups, can be a competitive advantage, since the only thing better than everything as code is no-code, meaning, no moving parts. For instance, with Firezone, you can make systems automatically accessible to Microsoft Teams, team by team. Adding someone to a team or kicking them from a team, can give them access or remove their access. That's a massive security gain and overhead reduction.
But the biggest differentiation seems to be solving corner cases that come up in real world use and rolling those out faster than firms can come up the curve in their own Zero Trust implementation. Tailscale must have an excellent forward-deployed product sensing practice, to either discover or listen to these problems from commercial users then tackle them and get it rolled out for all customers. Their docs are also use-case focused and self-service empowering: https://tailscale.com/kb/1300/production-best-practices with a clear understanding of how devs spend their time https://tailscale.com/kb/1360/developer-tools and generally organized by the "Diataxis" systematic approach to technical documentation authoring: https://diataxis.fr/
Finally, contrary to popular practice here, Tailscale don't have predatory pricing for SSO, no “SSO tax”.
The $0 plan includes SSO. Even if you're a one person shop, there's no reason not to get SSO going for yourself, every future SaaS you integrate with, and every future onboarding/offboarding will thank you. Switching to this later is far more costly than adopting it early, and we should all be supporting one another to make SSO (or Oauth2+OIDC) the norm instead of an "Enterprise Call Us" pricing discriminator.
It's great to see Firezone including OIDC in the starter plan, as that brings most of what anyone needs from "SSO", without most of the headaches. And this benefits Firezone too, they can't leak user passwords.
"Zero Trust" (such a terrible name for a pattern that actually means "enable trust on everything that matters") is a big deal, and more focus on this space is huge. It's worth building in this ecosystem, and worth paying attention to what overachievers are getting right.
If you remember NAC products from back in the day (policy-driven 802.1x and filtering, all designed to deal with the "chewy center" problem), this is like the overlay network version of that, and because it's all software it's much easier to deploy and manage.
Note, I am biased though as I work on an open source zero trust networking project - https://openziti.io/.
This helps contain breaches and lateral movement much better than VPNs. Plus, it plays nice with cloud and hybrid environments where traditional network perimeters get blurry.
One way to do that is to stick a simple reverse proxy in front of every app that does OIDC to your central IdP, and then arrange your network so that you cannot bypass that (eg using (micro)segmentation or something like IAP’s signed headers). My impression from reading Zscaler’s docs was that it was really just an over-complicated version of this without even doing the segmentation for you, but it sounds like it does do that bit too.
One difference not listed is MDM support. https://www.firezone.dev/kb/deploy/clients#provision-with-md... just tells you where to find the app but there's no parameters for configuring Firezone via zero-touch.
It's also not clear if Gateways can serve as Exit Nodes for egress clients (like a traditional VPN).
Lastly, Firezone Clients support only DNS over UDP/53 at this time. DNS-over-TLS and DNS-over-HTTPS upstream servers are not supported yet.