by jamilbk on 8/6/24, 5:52 PM with 89 comments
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 jkelleyrtp on 8/6/24, 7:57 PM
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.
by gchamonlive on 8/7/24, 12:56 PM
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.
by xyst on 8/7/24, 12:44 AM
Love that you are using rust!
by igorguerrero on 8/6/24, 7:55 PM
by jimmar on 8/6/24, 8:46 PM
by cedws on 8/6/24, 7:42 PM
by nmadden on 8/6/24, 8:01 PM
by mwest217 on 8/6/24, 6:18 PM
by phil-martin on 8/6/24, 8:22 PM
For a small example, when working from home, we want to connect to SMB shares over the vpn, with regular traffic going over the regular LAN interface of the computer. When the same person comes into the main office, just use the LAN. The simplest solution is to teach users to make sure they turn their VPN off when in the office, but that’s a super easy step to forget.
Could Firezone help managing these quality-of-life details for end users?
by computershit on 8/6/24, 6:43 PM
by ochronus on 8/7/24, 6:08 AM
by chetanbhasin on 8/6/24, 10:06 PM
I see the difference though. Tailscale goes with "secure this and that." It appears to attract people who don't already use a VPN, while you compare it straight to a VPN, which may be more enterprise crowd.
I'm not sure what your exact market is, but for a young startup at the very least, Tailscale marketing and UX appears a lot nicer.
by aos on 8/7/24, 2:53 AM
by taekwondo123 on 8/7/24, 9:11 AM
I see that tailscale addresses this now somewhat: https://tailscale.com/kb/1226/tailnet-lock
by somepleb on 8/7/24, 3:22 PM
by altdataseller on 8/6/24, 11:56 PM
by aborsy on 8/7/24, 7:48 PM