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!
by Andrey
Azimov