9 ms·
Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard
Hi HN! I'm Jamil Bou Kheir, founder of Firezone (https://www.firezone.dev https://www.firezone.dev), a remote access platform that is a replacement for legacy corporate VPNs. Built on WireGuard (a fast, modern VPN protocol), Firezone secures your team’s apps, networks and services using access policies synced with your identity provider. You deploy tiny, self-contained binaries into your infrastructure anywhere you need access, and your workforce uses our client apps to reach the resources they protect.
Here’s a demo: https://youtu.be/QEv7dJwKMvo 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 https://app.firezone.dev/try without signing up, and download clients from https://www.firezone.dev/kb/client-apps 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 https://www.github.com/firezone/firezone.
Thanks for reading, and I look forward to your feedback!
- mwest217 2y agoHow does this compare with e.g. Tailscale?
- jamilbk 2y agoGood question! The main difference is how access is managed. Instead of configuring ACLs, you define policies which are a 1:1 mapping between a user group (manually created or synced from your IdP) and the resource you want to allow access for. Another difference is how our load balancing / failover system works - it's automatic across all the Gateways in a particular Site.
- SeriousM 2y agoFor me as very simple customer with a few devices, is that a benefit? I didn't configured any acls in my little vpn town.
- jamilbk 2y agoFor simple access needs, in Firezone you would likely configure a CIDR resource and grant the Everyone group access to it, which mimics the setup of a traditional VPN. It is a couple extra clicks, though.
- mrbluecoat 2y agoThere's a chart on the homepage comparing to Tailscale and Twingate. One difference not listed is MDM support. https://www.firezone.dev/kb/deploy/clients#provision-with-mdm 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.
- jamilbk 2y agoWe don't support full-tunnel yet, but it's just around the corner. Track this issue if you're interested in its progress: https://github.com/firezone/firezone/issues/2667 https://github.com/firezone/firezone/issues/2667