Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard
115 points by jamilbk 39 days ago | hide | past | favorite | 89 comments
Hi HN! I'm Jamil Bou Kheir, founder of Firezone (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.

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!




Hey! I worked on WARP at Cloudflare. I believe Cisco has anyconnect and then there's zscaler.

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.


Oh man, I tried to use WARP for a project and it was the most confused, hard to understand product I've seen for a while. After a couple of hours of reading unhelpful support pages and trying increasingly random settings I simply gave up and used tailscale instead, which worked instantly.

I'm sure it wasn't the part of the product you worked on but the onboarding experience, wow, just terrible.


Through OpenZiti into the mix too - https://openziti.io/. Its open source and was designed from the ground up with zero trust, SDN, and deny-by-default principles. It also includes SDKs to allow developers to embed ZTN as part of the SDLC. We also built zrok (https://zrok.io/) on top of it, as a demonstration of a 'ziti-native' app, and being a better Ngrok.


OpenZiti looks so enticing but it is certainly a completely different world.

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


The biggest installation is a cyber security unicorn who whitelabels the commercial version of OpenZiti (NetFoundry) which they are selling to many large enterprises. They have hundreds of thousands of endpoints deployed. There is also a massive OT ICS OEM is embedding NetFoundry into its industrial routers, PLCs, etc for all types of connectivity, including machine to machine in factories. The same technology is being used for tactical military networks, with drones connecting to servers. Its being deployed in critical grid infrastructure. A hyperscaler is adopting it to replace hundreds of thousands of VPNs as well as build a multi-cloud zero trust offering for server to server workloads.

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.


> A hyperscaler is adopting it to replace hundreds of thousands of VPNs as well as build a multi-cloud zero trust offering for server to server workloads.

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)


You could use OpenZiti together with Cilium/Calico, there are some distros, eg., https://kubezt.com/ which do that (though in truth, KubeZT has moved to Istio for E-W, uses OpenZiti for N-S. OpenZiti does a lot of things that service mesh technologies do not, for example, extending outside of the cluster (incl. to non-K8S workloads), allowing closing of inbound FW ports, providing a private DNS outside of cluster, removing the need for VPNs, L4 loadbalancers, MPLS, SDWAN, public DNS etc.

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?


> You could use OpenZiti together with Cilium/Calico, there are some distros, eg., https://kubezt.com/ which do that (though in truth, KubeZT has moved to Istio for E-W, uses OpenZiti for N-S. OpenZiti does a lot of things that service mesh technologies do not, for example, extending outside of the cluster (incl. to non-K8S workloads), allowing closing of inbound FW ports, providing a private DNS outside of cluster, removing the need for VPNs, L4 loadbalancers, MPLS, SDWAN, public DNS etc.

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.


Ahh, thats cool. Note, the app embedded capabilities of OpenZiti becomes very interesting in this scenario, for example, our Python SDK working with Boto3 for AWS S3 - https://blog.openziti.io/extend-access-to-a-private-s3-bucke....

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.


> 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.


> 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).

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.


Oh so that allows it to run in-process?

That's cool, I did that for an HTTP forwarding thing a while back.


Yes, indeed, this blog gives a great view on it - https://blog.openziti.io/go-is-amazing-for-zero-trust - using Golang and HTTP examples. My favourite part:

"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."


Well that's also true for Firezone :)

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.


Maybe we are referring to different things when we say 'process'... I am not aware (happy to be educated) of Firezone having SDKs to embed the zero trust overlay running directly in an application, i.e., in the app process and memory.

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.


As a WARP user that has experienced a lot of problems, I'm glad that Cloudflare is allowing WARP users to switch from wireguard to MASQUE. I'm hopeful this will solve a lot of our issues.


Hm, is Wireguard getting blocked by middleboxes or something?


Sometimes yes. MASQUE just looks like normal TLS port 443 traffic so it's less likely to be prevented. Other issues we had were just bugs with the WARP wireguard implementation regarding how the tunnel is built in Windows. I imagine it works better on Linux or MacOS which is likely what the developers were running when they designed WARP.


Depends. MASQUE implies QUIC and a lot of coporate networks still block QUIC, forcing a fallback to TCP (for web browsers).

Not sure how they want to address this in case of WARP?

Nevertheless, MASQUE is some pretty exciting development in the network space.


Ah that's tough because Wireguard being UDP is a selling point for us at Firezone


Ah yes, don't get me started on all the fun edge cases involved in supporting cross platform network stacks and all their subtle tunnel API differences :-)

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!


At my last job, I implemented Firezone on AWS and it worked like a charm.

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.


Sounds like you had a cool experience with Firezone back in the day. Since you mentioned alternatives, have you checked out Netmaker? It's another open-source option (note I work there)


Wow, a product that hasn’t shoehorned AI/LLM into their offerings. Will be following.

Love that you are using rust!


We use it a work, didn't know you guys were fresh in the biz, our dev ops guy switched us to you guys, I had no problem, I love that it uses wireguard, our previous provider was a PITA :)


In the spirit of constructive feedback, spend the time and effort to record your product demonstrations in a more professional environment. Or generate a fake background at a minimum.


In the spirit of sheepish confession: that is my fault. I always tell founders to make raw, unprofessional videos for their Launch HNs. In fact, here is my standard blurb about it:

"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'm probably in the minority, but I actually really liked the scrappy, you-can-trust-us-because-I'm-not-wearing-a-tie vibe :D


Appreciate the feedback! Will certainly plan to take the product demos up a notch going forward.


I'd have definitely liked if the demo video was at least 1080p.


I'm a big fan of Tailscale but it's unfortunate that it's proprietary, so it's really nice to see an open source alternative. The commercial pricing also looks very reasonable. Wishing your product much success.


Second that.

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 have a few intrepid users self-hosting the entire Firezone stack, but we don't have documentation to support it (yet), and wouldn't recommend it for production. It's something we'd like to write and maintain eventually, even if only for smaller / hobby deployments.

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...


Thank you so much. Will check it out and probably create a pull request to add the documentation while I'm implementing it.


Do you think purchasers within enterprises especially care if it's a proprietary or commercially-supported FOSS offering?


Anecdotal but the company I work for does. But, not for the reasons the wider community cares.

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.


They do if they are building it into their product/commercial offering. Less so if its a direct and internal usage.


Yes. A shitload of legal nuance depending on what you choose here. (Software supply chain issues are increasingly important nowadays, and executives usually care about this stuff more, because it can carry huge risks.)


Those with purchasing 'influence' might. Accounts payable? No.


Thanks for the support!


This comment sounds like a promo for Tailscale. It's actually a suggestion to Firezone to model after what Tailscale are getting right. We need competition in this space, but tooling non-SV businesses can leverage. Tailscale is pulling this off well.

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 prefer "End to End Security" or "Continuous Verification" to the Zero Trust term. But it seems the Zero Trust term is so ingrained now that everyone who has a product to sell will use it.


I don’t really get the threat model of these “zero trust” appliances and how they are really different from a VPN. Can someone explain it to me? It still looks very much like a perimeter.


It's a "virtual" or "overlay" central reference monitor for the whole network --- imagine collapsing an entire campus network down to a single firewall --- which makes it really easy to draw arbitrary internal perimeters. The real customers for these products all tend to have group-based policies.

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.


I would add, doing Zero Trust Networking properly means deny by default (VPNs are open by default), service based access (not whole host or network), microsegmentation (not whole network), and least privilege. You should also use posture checks to ensure the end device is compliant and personally I prefer 'authenticate before connect' with outbound only connections from source and destination.

Note, I am biased though as I work on an open source zero trust networking project - https://openziti.io/.


I took tptacek’s comment as implying that ZTNA solutions do do microsegmentation. Otherwise, if I get a shell in one app and have access to the entire network then what was the point of any of it? Are you saying they don’t do microsegmentation?


Yes: "microsegmentation" is a good way to describe one strategy (the most popular one) for retrofitting a notion of OMB-style "Zero Trust" onto existing networks. It's the selling point of things like this.


Agreed. My point was that ZTNA requires more than just micro segmentation, it should also include deny by default, service based access, least privilege, endpoint posture checks etc.


Not really, no.


Oh ok. I’ve been reading a lot of zscaler zpa docs at work and didn’t come away with that impression at all. (The Zscalar docs are awful though).


Zero trust actually goes way beyond traditional VPNs. A key difference is granular access control and continuous verification. With zero trust, you're not only punching a hole through a firewall - you're creating dynamic, context-aware access policies for each user and device.

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.


Sure, zero trust implies those things, but I was asking specifically about these kinds of all-in-one “zero trust appliances”. For me, as an AppSec specialist, I’d say ZT is primarily about making sure all your apps enforce authN/Z regardless of whether the users are on an internal network or not.

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 idea of “zero trust appliances” is that you can reduce the attack surface from the external network, that is how Zscaler positions it, to make you apps 'dark'. IMHO though, the logical conclusion is to give every application, as part of the software development lifecycle its own private network, which implements zero trust principles - least privilege, microsegmentation, default deny, strong identity, device authentication, and more.

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/.


But a simple gateway/ELB can protect your apps from the public internet. (But unless you’re pushing a root CA cert to all client devices then those apps aren’t “dark” in any sense due to CT logs). Zscalar’s ZPA docs say:

> [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?


The gateway/ELB has inbound ports and 'listens' on the WAN interface for incoming connections. Therefore it can be subject to external network attacks, and be compromised if a CVE etc exists.

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.


The Zscaler exchange also listens to incoming connections, as does the OpenZiti edge router. How is this different? I’ve just swapped one vendor’s edge appliance (eg AWS ELB) for another. A CVE in either has the same impact, no?

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.


I cannot speak for Zscaler in this scenario, but I can explain why its different and reduced risk for OpenZiti/NetFoundry (I literally posted on this topic yesterday on LN, blog post coming soon - https://www.linkedin.com/posts/philipleonardgriffiths_no-lis...)

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.


p.s., app embedded makes network attacks almost impossible as you no longer have a listening port on the underlay network, well described here - https://blog.openziti.io/go-is-amazing-for-zero-trust


How does this compare with e.g. Tailscale?


Good 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.


For me as very simple customer with a few devices, is that a benefit? I didn't configured any acls in my little vpn town.


For 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.


There'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-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.


We 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


One of the pain points I’ve experienced with configuration of traditional VPNs is when devices physically connect to different parts of the network when staff travel between home and different offices.

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?


This is a fairly common scenario and one that we had in mind when building the NAT traversal implementation. The short answer is that you wouldn't need to sign out of Firezone when in the office -- the connection should hairpin off the nearest common router and go directly to the SMB share in this case.


This single handedly convinced me to try it out in my homelab!

Tailscale fails at this and I consider it fairly basic networking.


You can read more about how we came up with the current implementation here:

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....


Impressive work, congrats on the launch! Aside from the OSS perspective, how would you compare your service to Twingate?


Thanks! We're similar to Twingate in how we model resources, but our policy system has optional conditions you can apply to restrict access further, which works a bit differently. We expect to continue building in that area over time. We also use WireGuard as a transport while I believe Twingate operates over QUIC.


My understanding is that Twingate uses a service-based access model, rather than host/IP/ACL-based, as Wireguard defines the world.

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?


I may not be fully understanding the question, but I think you may be referring to DNS-based resources? Those will allow you to manage access to an app or service by its DNS name (wildcards supported). You can also use IP or CIDR resources as well of course.

In terms of scalability, are you referring to throughput or simply the complexity of policy management as the number of resources grows?


I refer to doing service based connections, abstracted away from whether its DNS, IP or something else. To do this you really need a private DNS function and to operate with attribute based access controls.

Complexity of policy mngt. I read that ACLs are fine at small scale but become a nightmare at larger enterprise scale.


Firezone's DNS-based routing is able to manage access to multiple services independently, even if they share the same IP address. So you could for example allow access to gitlab.company.com but not jira.company.com even if they were on the same webserver / loadbalancer.

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...


It's really exciting to see this space bloom! Congrats on the launch!


Since you're directly competing with Tailscale, you have to compare the websites. The landing pages and documentation are waaay nicer, IMHO.

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.


Congrats on the launch! Will definitely have to check it out. I see you’re using Phoenix/Liveview for the control plane. :-) How has that been working for you?


Thanks!

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.


The concern I have with these types of solutions (meaning Tailscale, Firezone, etc.), is that I need to trust the provider not to mess up or maliciously exchange keys with rouge devices. Is this the case with Firezone as well?

I see that tailscale addresses this now somewhat: https://tailscale.com/kb/1226/tailnet-lock


Firezone employee here. I believe we have an idea to let customers sign their keys so that they don't need to trust our portal not to rewrite keys. This is probably the same idea Tailscale hit on.

(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.


> maliciously exchange keys with rouge devices

Companies are slow to respond to the growing threat from adversarial make-up brushes.


I live by but two rules, private keys stay on the storage device they're first saved to, and makeup stays with the first person to use it.


Why somewhat? The client has to sign the key, and Tailscale can’t add public keys to the network.


Awesome to see so many solutions in this space and the rapid development. Do you plan to add mesh networking?


Not a comment on the actual product but did you use a specific template or stack on the app you show in the demo?


Are you referring to the macOS client app? It's built in Swift with an FFI bridge to the Rust-powered connectivity layer. Source is here: https://github.com/firezone/firezone/tree/main/swift/apple


I am referring to the web app


I think it's LiveView for the frontend-backend comms and Tailwind CSS for some of the frontend, not sure if that answers your question

-- (non-web) developer at Firezone


Tailscale does these things, and does them very well. We have been pretty happy with it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: