From eba9081ca73a19f1b37fd81c053e5401f9602d1c Mon Sep 17 00:00:00 2001 From: Jamil Date: Tue, 18 Jul 2023 15:31:00 -0700 Subject: [PATCH] Thicker animation strokes; clarify blogpost (#1800) --- website/public/images/firewall-block.svg | 14 +- website/public/images/firezone-1.0.svg | 18 +-- website/public/images/stateful-firewall.svg | 16 +- website/src/app/blog/firezone-1-0/readme.mdx | 69 ++++---- website/src/app/page.tsx | 149 +++++++++--------- website/src/app/product/early-access/page.tsx | 2 +- website/src/app/product/newsletter/_page.tsx | 6 +- website/src/app/product/roadmap/_page.tsx | 4 +- website/src/app/team/page.tsx | 13 +- .../src/components/Blog/SummaryCard/index.tsx | 2 +- .../src/components/EarlyAccessForm/index.tsx | 13 +- .../src/components/JoinOurCommunity/index.tsx | 4 +- website/src/components/RootLayout/index.tsx | 10 +- .../src/components/SalesLeadForm/index.tsx | 6 +- 14 files changed, 164 insertions(+), 162 deletions(-) diff --git a/website/public/images/firewall-block.svg b/website/public/images/firewall-block.svg index d5303110a..65ac9c8f4 100644 --- a/website/public/images/firewall-block.svg +++ b/website/public/images/firewall-block.svg @@ -1,27 +1,27 @@ - + - +<rect width="198.687176" height="299.794259" rx="0" ry="0" transform="matrix(.337169 0 0 0.502723 125.483062 24.643266)" fill="none" stroke="#ff7300" stroke-width="6" stroke-linejoin="round" stroke-dasharray="5,2"/><text dx="0" dy="0" font-family="&quot;eqYSHResvjl1:::Public Sans&quot;" font-size="14" font-weight="400" transform="translate(246.49456 104.365693)" fill="#1b140e" stroke-width="0"><tspan y="0" font-weight="400" stroke-width="0"><![CDATA[ you - + trusted entity - + untrusted entity - + firewall diff --git a/website/public/images/firezone-1.0.svg b/website/public/images/firezone-1.0.svg index d23587c25..70b3594fb 100644 --- a/website/public/images/firezone-1.0.svg +++ b/website/public/images/firezone-1.0.svg @@ -1,39 +1,39 @@ - + - +<rect width="198.687176" height="299.794259" rx="0" ry="0" transform="matrix(.337169 0 0 0.502723 125.483062 24.643266)" fill="none" stroke="#ff7300" stroke-width="6" stroke-dasharray="5,2"/><text dx="0" dy="0" font-family="&quot;elmZYSgX4Ii1:::Public Sans&quot;" font-size="14" font-weight="400" transform="translate(236.691399 97.461213)" fill="#1b140e" stroke-width="0"><tspan y="0" font-weight="400" stroke-width="0"><![CDATA[ protected entity - + untrusted entity - + trusted entity - + access broker - + stateful firewall - +]]> diff --git a/website/public/images/stateful-firewall.svg b/website/public/images/stateful-firewall.svg index 23fc2a0a2..cac55ac66 100644 --- a/website/public/images/stateful-firewall.svg +++ b/website/public/images/stateful-firewall.svg @@ -1,30 +1,30 @@ - + - +<rect width="198.687176" height="299.794259" rx="0" ry="0" transform="matrix(.337169 0 0 0.502723 125.483062 24.643266)" fill="none" stroke="#ff7300" stroke-width="6" stroke-linejoin="round" stroke-dasharray="5,2"/><text dx="0" dy="0" font-family="&quot;eNtxarskcJz1:::Public Sans&quot;" font-size="14" font-weight="400" transform="translate(246.49456 104.365693)" fill="#1b140e" stroke-width="0"><tspan y="0" font-weight="400" stroke-width="0"><![CDATA[ you - + untrusted entity - + trusted entity - + untrusted entity - + stateful firewall @@ -32,6 +32,6 @@ firewall diff --git a/website/src/app/blog/firezone-1-0/readme.mdx b/website/src/app/blog/firezone-1-0/readme.mdx index 0e737dbf3..f75643e22 100644 --- a/website/src/app/blog/firezone-1-0/readme.mdx +++ b/website/src/app/blog/firezone-1-0/readme.mdx @@ -33,14 +33,13 @@ started building what became the first version of Firezone. When we [launched on Hacker News](https://news.ycombinator.com/item?id=28683231) nearly two years ago, we never envisioned Firezone to be more than a simple tool -deploying your own WireGuard-based VPN server. +for deploying your own WireGuard-based VPN server. Fast-forward [4,500 GitHub stars](https://github.com/firezone/firezone/stargazers), a [Y Combinator backed funding round](https://techcrunch.com/2022/03/30/ycombinator-open-source-startups-winter-22-demo-day/), and [130 releases](https://github.com/firezone/firezone/releases) later -- -Firezone has now grown into something more than just a self-hosted tool to -manage your WireGuard configurations. +Firezone has now grown into something more. We now count over 3,000 Firezone instances running in the wild (possibly much more -- we allow users to @@ -57,13 +56,13 @@ hobbyists, schools, non-profits, and businesses with hundreds of employees. To be clear, Firezone is successful in large part because WireGuard itself is successful. In an industry brimming with enterprise security bloatware and -endless acronyms, WireGuard's a breath of fresh air. Every issue I've thought I -had with it turned out to be user error. How we ever got by without it is a -mystery to me. +acronyms galore, WireGuard's a breath of fresh air. It's almost boring how well +it works. I suppose I could go on and on about WireGuard's strengths, but I +won't. After all, this post is supposed to be about Firezone 1.0. -But I could go on and on about WireGuard's strengths. Let's back up for a minute --- what is a VPN, and why is one needed at all? To answer that we'll need to go -back to the formation of the Internet itself. +So let's back up -- what is a VPN anyway, and why is one needed at all? To +answer that we'll need to go back in time to the formation of the early +Internet. #### The purpose of a VPN @@ -73,11 +72,11 @@ universities, and other large institutions could justify the cost. So when you connected your organization to the Internet and began receiving packets, it was clear which entity it was from based on its allocated IPv4 -address range. Since there were so few entities connected, it was clear who you -communicated with. It was clear who to contact (and blame) in case any issues -arose. +address range. Since there were so few entities connected, you could easily know +who you were communicating with, and who to contact (and blame) in case any +issues arose. -But, as access to the Internet became cheaper, more types of entities could +But as access to the Internet became cheaper, more types of entities could afford to connect. As more entities connected, the number of resources on the Internet grew, and its [value increased quadratically](https://en.wikipedia.org/wiki/Metcalfe%27s_law). @@ -102,21 +101,22 @@ do. /> -And this worked well for some time. However, as the Internet grew even larger, a -problem arose: firewalls required you to know _in advance_ who you'd like to -communicate with, adding them to your configuration, and likewise removing the -ones you didn't. As you might imagine, it quickly became unwieldy to keep these -configurations up to date. +And this worked well for some time. However, the Internet grew even larger (as +networks tend to do). And then a problem arose: firewalls required you to know +_in advance_ who you'd like to communicate with, adding them to your +configuration, and likewise removing the ones you didn't. As you might imagine, +it quickly became unwieldy to keep these configurations up to date. So a clever solution was developed: what if you could dynamically add and remove -entities to the firewall configuration on the fly? +entities to the firewall configuration, on the fly? -And thus, stateful firewalls were born. I should pause here and clarify that +And thus stateful firewalls were born. I should pause here and clarify that stateful firewalls are sometimes confused with [Network Address Translation (NAT)](https://en.wikipedia.org/wiki/Network_address_translation), since they're often found on the same device. But there's an important distinction: A stateful firewall _remembers_ stuff it's seen in order to to -update its configuration dynamically, whereas NAT can behave statically. +update its configuration dynamically, whereas a NAT device is primarily +concerned with static operation. Stateful firewalls exist in nearly every consumer router and datacenter gateway connected to the Internet today. There's a very high likelihood the Internet @@ -133,7 +133,7 @@ been largely successful at serving their intended purpose. /> -However, this post wouldn't be very interesting if we stopped there. +But this post wouldn't be very interesting if we stopped there. You see, there's still one fundamental problem with stateful firewalls, particularly as it relates to remote access. For two-way communication to occur, @@ -177,7 +177,7 @@ Then how does an entity come to be trusted? We still authenticate them as usual, but there's a key difference: with ZTA, we authenticate entities each time the communication is requested, on the fly. Not once at the perimeter. And since the perimeter is gone, the protected entity itself (or a proxy) authenticates the -untrusted entity. But wait, what happened to the firewall? +untrusted entity. But wait, hold on a minute -- what happened to the firewall? This presents a dilemma. If we use a firewall to protect entities, they're shielded outside the perimeter, but left unprotected inside the perimeter. And @@ -214,24 +214,27 @@ works as follows: So we're able to both authenticate the untrusted entity at the time of request, yet also keep our protected entity behind a firewall to keep it invisible to the public Internet. In fact, _both_ entities can live behind a stateful firewall -and the technique would still work -- the principles are the same. +and this technique would still work -- the principles are the same. -As it turns out, this approach is nothing new. It's how web browsers and VoIP -systems have established peer to peer connections for low-latency audio and -video chat for decades. +As it turns out, this approach is +[nothing new](https://bford.info/pub/net/p2pnat/). It's how web browsers and +VoIP systems have established peer to peer connections for low-latency audio and +video chat [for over a decade](https://en.wikipedia.org/wiki/WebRTC). -Firezone 1.0 makes this process transparent, but also goes one step further by -exposing granular controls to allow or deny access based on attributes like -which group a user is a member of and so on. +Firezone 1.0 not only makes this process seamless for connectivity, but also +goes one step further by exposing granular controls to allow or deny access +based on attributes like which group a user is a member of and so on. Of course if you wanted to use Firezone 1.0 like a traditional perimeter-based VPN and then transition to finer-grined access controls over time, you can do that as well. We understand the realities of legacy processes and systems, so we designed 1.0 to be flexible enough to suit the needs of both. -And while we were at it, we decided to build a slew of new features for 1.0 as -well, most notably a cloud-managed admin portal and native clients. Check our -[product roadmap](/product/roadmap) for more details on what's coming in 1.0. +While we were at it, we decided to build a slew of new features for 1.0 in +addition to the architecture improvements laid out in this post. Most notably, a +cloud-managed admin portal, native clients, and high availability support. But +there's much more. Check our [product roadmap](/product/roadmap) for more +details on what's coming in 1.0. #### Next steps diff --git a/website/src/app/page.tsx b/website/src/app/page.tsx index 44a678958..a692e8c74 100644 --- a/website/src/app/page.tsx +++ b/website/src/app/page.tsx @@ -22,16 +22,16 @@ export default function Page() { return ( <>
-
+

Fast, effortless secure access.

-

+

Firezone is an open-source remote access platform built on WireGuard®, a modern VPN protocol that's 4-6x faster than OpenVPN. Deploy on your infrastructure and start onboarding users in minutes.

-
+