[HN Gopher] Launch HN: Firezone (YC W22) - Zero-trust access pla...
___________________________________________________________________
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), 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!
Author : jamilbk
Score : 56 points
Date : 2024-08-06 17:52 UTC (5 hours ago)
| mwest217 wrote:
| How does this compare with e.g. Tailscale?
| jamilbk wrote:
| 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.
| SeriousM wrote:
| 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.
| jamilbk wrote:
| 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.
| computershit wrote:
| Impressive work, congrats on the launch! Aside from the OSS
| perspective, how would you compare your service to Twingate?
| jamilbk wrote:
| 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.
| PLG88 wrote:
| 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?
| jamilbk wrote:
| 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?
| cedws wrote:
| 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.
| jamilbk wrote:
| Thanks for the support!
| dotBen wrote:
| Do you think purchasers within enterprises especially care if
| it's a proprietary or commercially-supported FOSS offering?
| igorguerrero wrote:
| 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 :)
| jkelleyrtp wrote:
| 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.
| jamilbk wrote:
| 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!
| nmadden wrote:
| 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.
| tptacek wrote:
| 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.
| nmadden wrote:
| 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).
| phil-martin wrote:
| 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?
| jamilbk wrote:
| 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.
| jimmar wrote:
| 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.
| jamilbk wrote:
| Appreciate the feedback! Will certainly plan to take the
| product demos up a notch going forward.
| dang wrote:
| 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.
| chetanbhasin wrote:
| 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.
___________________________________________________________________
(page generated 2024-08-06 23:00 UTC)