Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard
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:...
89 comments
[ 2.9 ms ] story [ 245 ms ] threadOne 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.
As you are based on WG, have you somehow paperer over that to move away from network trust and lack of scalability (that I read across HN/Reddit/YT) inherent to other WG based solutions?
In terms of scalability, are you referring to throughput or simply the complexity of policy management as the number of resources grows?
Complexity of policy mngt. I read that ACLs are fine at small scale but become a nightmare at larger enterprise scale.
It took a couple iterations to get it right - lots of fun edge cases involved. We ended up having to build automatic NAT64 and 46 for DNS resources to handle some of them. We wrote a post on how this works: https://www.firezone.dev/blog/how-dns-works-in-firezone
In terms of attributes for allowing access, we currently support time-based, country/region-based, auth method, and IP-based, with more planned: https://www.firezone.dev/kb/deploy/policies#conditional-acce...
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.
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...
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.
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.
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!
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
So we have not finished our job to make OpenZiti the equivalent to Linux in that every just uses it by default, but we will get there ;)
You raise an interesting point. We provide flexibility for ingress/egress... do not like proxies/sidecars, go in either opposite direction, (1) ZTAA, Zero Trust App access with SDK app embedded via SDLC, (2) ZTNA, Zero Trust Network Access via appliance deployments in DMZ/VP/VNET etc (the one you mention is ZTHA, Host Access). Each of ZTNA/HA/AA have different pros and cons based on your requirements and use case.
This one is the most compelling to me! A while back I was building a small cloud provider and this was the use case I was looking really closely at OpenZiti for.
Thanks for sharing!
>You raise an interesting point. We provide flexibility for ingress/egress... do not like proxies/sidecars, go in either opposite direction, (1) ZTAA, Zero Trust App access with SDK app embedded via SDLC, (2) ZTNA, Zero Trust Network Access via appliance deployments in DMZ/VP/VNET etc (the one you mention is ZTHA, Host Access). Each of ZTNA/HA/AA have different pros and cons based on your requirements and use case.
Ah so this would work if:
1) all the apps were my own
2) I was sitting on top of a major cloud/managed colo (I'm just sitting on top of infra providers like hetzner)
The project I was working on is not so active right now but it's still chugging along (I use it)... I was looking at things like OpenZiti as a k8s CNI provider, or used along with something like Cilium/Calico (but then they'd both promise network security in-between workloads and overlap)
Yes, OpenZiti very much focus on private apps, whether COTS or inhouse developed.
Oh, I should note too, while we have a bunch of ways to deploy OpenZiti on K8S today, we are in the process of building/releasing an admission controller and an ingress controller for OpenZiti.
Whats the project you work on?
Yeah Istio is a hard no for me... And yeah I definitely appreciate that OpenZiti does a lot more than service meshes do! I personally try to avoid service meshes (if I were to use one, I'd go with linkerd).
I'm just not convinced that many people need a service mesh -- I haven't really needed one yet, but maybe I'm just not at the right scale/etc.
> Oh, I should note too, while we have a bunch of ways to deploy OpenZiti on K8S today, we are in the process of building/releasing an admission controller and an ingress controller for OpenZiti.
This is awesome -- I really like my current admission controller though (Traefik), it's FANTASTIC. I think moving ingress controllers might be a large lift for people (it would be for me).
> Whats the project you work on?
I don't really work on it actively these days (haven't in a while) but https://nimbusws.com
Looking forward to picking it back up more actively in the future though, for now I use it for some small background services.
I get that. Would need to check if we can integrate Ziti into Traefik in the same way we did for Nginx (https://blog.openziti.io/nginx-zerotrust-api-security) and Caddy (https://blog.openziti.io/put-some-ziti-in-your-caddy), which we did respectively using the C and Golang SDKs. Therefore you wouldn't need to change your ingress, you would just load Ziti as a module in it.
Yeah, this is why I was thinking that the easiest way to integrate would be a sidecar (and in general for random web serving payloads). I'm not ruling it out, but this was the major stopper -- it seemed easier to just rely on Cilium/Calico underneath to keep east-west comms encrypted between apps and k8s nodes.
Clarification: You could use Traefik's ingress controller in tandem with a hypothetical OpenZiti ingress controller. You'd set `ingressClass: openziti` on those Ingress resources you wish OpenZiti to handle. Nothing would prevent you from creating two Ingress resources for the same ClusterIP service: one each for Traefik and OpenZiti.
That's cool, I did that for an HTTP forwarding thing a while back.
"Now, your server has no listening ports on the underlay network. It's literally unattackable via conventional IP-based tooling. Seriously, stop and consider that for just a moment. By adopting an OpenZiti SDK into the server, all conventional network threats are immediately useless."
It's a tradeoff between in-process and out-of-process though. It's nice that Firezone Gateways don't have access to the service's memory space and can't crash the process, but it's also nice that an in-process Gateway equivalent doesn't need to loop through the network to reach its service.
Do they support this?
I hear you on having 'out of process', that's why OpenZiti also has tunnellers for deploying on host as well as virtual appliances to run in the DMZ/VNET/VPC etc. I was only aware of Firezone supporting those 2 deployment models.
Not sure how they want to address this in case of WARP?
Nevertheless, MASQUE is some pretty exciting development in the network space.
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.
The beauty of this approach is that you eliminate a whole class of vulnerabilities (see 'secure by default from CISA), that is, network/IP attacks, without changing the users experience (they just access the app).
Another key aspect is that this approach should be applied to every use case, not just client to server. All of this is possible on the open source project I work on, OpenZiti - https://openziti.io/.
> [ZPA] mitigates lateral threat movement through advanced segmentation
https://www.zscaler.com/products/zscaler-private-access
So it must be doing some segmentation at the network level, otherwise what does that statement mean?
Zscaler Private Access makes outbound connections so that you can deny all inbound connections and not be subject to external network attacks. It also creates application-specific connections, rather than a full tunnel so that each connection is inherently microsegemented and inaccessible to anything outside of that tunnel.
We do the same thing on the open source project I work on, OpenZiti (https://github.com/openziti), though our platform is more like ZPA on steroids.
Application specific connections are great and everything. But if a web app has a log4shell-like vulnerability then that app-specific connection means nothing if the app isn’t also isolated at the network level to prevent lateral movement.
PS - denying incoming connections doesn’t eliminate all network attacks by any means.
First things first. Yes. If a vulnerability exists in the overlay network that would allow an attacker to bypass the security of the zero trust network, but what does that mean in practice? Well, to do this they would need to: - (1) need to bypass the mTLS requirement necessary to connect to the data plane (note, each hope is uses its own mTLS with its own, separate key). - (2) have a strong identity that authorizes them to connect to the remote service in question (or bypass the authentication layer the controller provides through exploits; note again, each app uses separate and distinct E2EE, routing, and keys) - (3) know what the remote service name is, allowing the data to target the correct service (not easy as OpenZiti has its own private DNS that does not need to comply to TLDs) - (4) bypass whatever "application layer" security is also applied at the service (ssh, https, oauth, whatever) - (5) know how to negotiate the end to end encrypted tunnel to the 'far' identity
So yes, if they can do all that, then they'd definitely be able to attack that remote service.
But wait, I said "remote service", not "remote services". Thats right, all that work and compromises and they only have access to 1 single service among hundreds, thousands, or potentially millions of services. Lateral movement is almost mpossible. So the attacker would have to repeat each of the 5 steps for every service.
Finally, how would they know which company sits behind which OpenZiti fabric. Thats right, they don't. So its pot luck if its even against the target they want to try and exploit.
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?
Tailscale fails at this and I consider it fairly basic networking.
https://github.com/firezone/firezone/issues/3553
We didn't invent these techniques. Host candidates are part of standard ICE:
https://datatracker.ietf.org/doc/html/rfc8445#section-5.1.1....
"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 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.
-- (non-web) developer at Firezone
Love that you are using rust!
Erlang/OTP has so far been an excellent platform to build on for a product like Firezone. We chose it specifically for its reputation for powering soft realtime systems. Phoenix Channels are an added bonus that allow us to push all updates where they need to go, in just a few hundred lines of code.
We couldn't be happier with the stack choice.
I see that tailscale addresses this now somewhat: https://tailscale.com/kb/1226/tailnet-lock
Companies are slow to respond to the growing threat from adversarial make-up brushes.
(I can't find this idea in the issue tracker and I don't think it's on the roadmap yet, but we've discussed it.)
Unfortunately there is a big convenience-security tradeoff, managing your own keys and certs is a lot of work.
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.