diff --git a/website/public/images/blog/how-dns-works-in-firezone/dns-based-traffic-routing.svg b/website/public/images/blog/how-dns-works-in-firezone/dns-based-traffic-routing.svg index 9f7effc2f..beac26085 100644 --- a/website/public/images/blog/how-dns-works-in-firezone/dns-based-traffic-routing.svg +++ b/website/public/images/blog/how-dns-works-in-firezone/dns-based-traffic-routing.svg @@ -1,6 +1,6 @@ - + @@ -10,7 +10,7 @@ - + @@ -24,13 +24,13 @@ - - + + - - - + + + @@ -48,25 +48,23 @@ - + - - + + - + - - - - + + @@ -75,7 +73,7 @@ - + diff --git a/website/src/app/blog/how-dns-works-in-firezone/readme.mdx b/website/src/app/blog/how-dns-works-in-firezone/readme.mdx index f0be7b00e..1b3f296a4 100644 --- a/website/src/app/blog/how-dns-works-in-firezone/readme.mdx +++ b/website/src/app/blog/how-dns-works-in-firezone/readme.mdx @@ -283,13 +283,21 @@ default nameservers as if Firezone didn't exist. For DNS queries that do match a defined Resource, however, it behaves a bit differently. Instead of forwarding the query to your default nameservers, our special stub -resolver first asks Firezone's Policy Engine to authorize the query for the -Resource in question. +resolver generates a special, internal IP for the Resource and responds +immediately with that, storing the IP in a lookup table. -If approved, the Policy Engine forwards the query to a Gateway that's available -to serve the Resource. The Gateway then resolves the query for the Resource -(using _its_ stub resolver) and returns the final result all the way back to the -stub resolver running inside the Client. +Upon seeing packets through the tunnel matching the IP in the lookup table, the +Client generates a request to the Policy Engine to authorize the traffic. If +approved, the Policy Engine forwards the IP and DNS name corresponding to the +Resource to a Gateway that's available to serve the Resource. + +The Gateway then resolves the actual IP address for the Resource (using _its_ +stub resolver) and stores a mapping between it and the special, internal IP we +generated earlier. + +When the Gateway sees traffic for the special, internal IP, it translates +translates it back to the actual IP of the Resource and forwards the traffic +along to the Resource. If you're new to Firezone, read more about @@ -298,10 +306,6 @@ stub resolver running inside the Client. docs. -Here's where things get interesting: instead of passing the resolved IP address -as-is back to the application, the stub resolver generates a dummy IP address -for it and returns that instead. - + If you need more than 55,000 concurrent connections, you can increase the + number of IP addresses associated to the AWS NAT Gateway. See [AWS's + documentation](https://repost.aws/knowledge-center/vpc-resolve-port-allocation-errors) + for more information. + + We've tested with `t3.nano` instances which still work quite well for most applications. However, you may want to consider a larger instance type if you -have a high volume of traffic or lots of concurrent connections. +have a high volume of traffic or lots of concurrent connections. See +[Gateway sizing recommendations](/kb/deploy/gateeways#sizing-recommendations) +for some general guidelines depending on your expected traffic. ## Deployment diff --git a/website/src/app/kb/automate/terraform/azure/readme.mdx b/website/src/app/kb/automate/terraform/azure/readme.mdx index 6b7cd383e..a7f1aa329 100644 --- a/website/src/app/kb/automate/terraform/azure/readme.mdx +++ b/website/src/app/kb/automate/terraform/azure/readme.mdx @@ -51,9 +51,18 @@ Gateways. There's no limit to the number of Firezone Gateways you can deploy in a single Vnet. A basic Azure Autoscale configuration is provisioned as part of the linked module. + + If you need more than 64,512 concurrent connections, you can increase the + number of public IP addresses reserved for the Azure NAT Gateway. See [Azure's + documentation](https://learn.microsoft.com/en-us/azure/nat-gateway/troubleshoot-nat-connectivity) + for more information. + + We've tested with `Standard_B1ls` instances which still work quite well for most applications. However, you may want to consider a larger instance type if you -have a high volume of traffic or lots of concurrent connections. +have a high volume of traffic or lots of concurrent connections. See +[Gateway sizing recommendations](/kb/deploy/gateeways#sizing-recommendations) +for some general guidelines depending on your expected traffic. ## Deployment diff --git a/website/src/app/kb/automate/terraform/gcp/readme.mdx b/website/src/app/kb/automate/terraform/gcp/readme.mdx index 88de75908..8ec96278c 100644 --- a/website/src/app/kb/automate/terraform/gcp/readme.mdx +++ b/website/src/app/kb/automate/terraform/gcp/readme.mdx @@ -49,9 +49,18 @@ Simply update the number of replicas to deploy more or fewer Firezone Gateways. There's no limit to the number of Firezone Gateways you can deploy in a single VPC. + + If you need more than 64,512 concurrent connections, you can increase the + number of public IP addresses reserved for the Cloud NAT. See [Google's + documentation](https://cloud.google.com/nat/docs/ports-and-addresses#ports) + for more information. + + We've tested with `f1-micro` instances which still work quite well for most applications. However, you may want to consider a larger instance type if you -have a high volume of traffic or lots of concurrent connections. +have a high volume of traffic or lots of concurrent connections. See +[Gateway sizing recommendations](/kb/deploy/gateeways#sizing-recommendations) +for some general guidelines depending on your expected traffic. ## Deployment diff --git a/website/src/app/kb/deploy/dns/readme.mdx b/website/src/app/kb/deploy/dns/readme.mdx index 9bb1a3d5a..f8a474925 100644 --- a/website/src/app/kb/deploy/dns/readme.mdx +++ b/website/src/app/kb/deploy/dns/readme.mdx @@ -15,11 +15,11 @@ Read more below to understand how it works and how to configure it. ## How DNS works in Firezone -Each Firezone Client embeds a lightweight DNS proxy used to route queries to an -appropriate Gateway for resolution. +Each Firezone Client embeds a lightweight DNS resolver used to route queries to +an appropriate Gateway for resolution. When a user signs in, the Client configures the host operating system to use -this proxy as the default resolver for all queries on the system. +this resolver as the default resolver for all queries on the system. This is why you'll commonly see `100.100.111.1` or `fd00:2021:1111:8000::100:100:111:0` as the DNS server responding to DNS queries @@ -32,11 +32,20 @@ when the Firezone Client is signed in. docs](/kb/architecture/critical-sequences#dns-resolution). -When the proxy sees a DNS query for a Resource, it asks the portal for a healthy -Gateway to handle the query. The Gateway resolves the query using its system -resolver and sends the result back to the proxy, which generates a mapped IP to -the Resource's actual IP address. The final mapped IP is then returned to the -application making the query. +When the resolver sees a DNS query for a Resource, it generates a mapped, dummy +IP and responds with that IP. The mapped IP is used to route traffic +corresponding to the Resource in question to a healthy Gateway. While this is +happening, the Gateway receives the query via the control plane and resolves it +using its system resolver, storing the result in a lookup table. + +When the Gateway sees traffic coming from the Client for the mapped IP, it +translates the mapped IP back to the actual IP address of the Resource and +forwards the traffic to the Resource. + +This happens in a fraction of a second and is completely transparent to the end +user. The Client host's system resolver is never used for resolving DNS queries +for Firezone Resources, and never sees the actual IP addresses of DNS Resources +in your account, ensuring your DNS data remains private and secure. For example, if `github.com` was added as a Resource, an `nslookup` might return `100.96.0.1` as its IPv4 address: @@ -51,9 +60,16 @@ Name: github.com Address: 100.96.0.1 ``` -If the query doesn't match a Resource, the proxy forwards the query to one of +If the query doesn't match a Resource, the resolver forwards the query to one of the [upstream resolvers](#configuring-client-dns-upstream-resolvers) if -configured. +configured in your account. Otherwise, it forwards the query to the default +system resolver on the Client host. + + + Firezone only intercepts queries for the `A`, `AAAA`, and `PTR` record types + for your DNS Resources. All other record types are forwarded to the upstream + resolver(s). + ## Configuring Client DNS upstream resolvers diff --git a/website/src/components/KbSidebar/index.tsx b/website/src/components/KbSidebar/index.tsx index 590b68636..fa6b21f0e 100644 --- a/website/src/components/KbSidebar/index.tsx +++ b/website/src/components/KbSidebar/index.tsx @@ -20,7 +20,7 @@ export default function KbSidebar() { Overview Quickstart guide - + Overview Sites @@ -76,7 +76,7 @@ export default function KbSidebar() { - + Overview @@ -138,7 +138,7 @@ export default function KbSidebar() { - + Overview diff --git a/website/src/components/RootNavbar/index.tsx b/website/src/components/RootNavbar/index.tsx index 10fa8eaf9..3a4d9a297 100644 --- a/website/src/components/RootNavbar/index.tsx +++ b/website/src/components/RootNavbar/index.tsx @@ -51,8 +51,8 @@ const navbarTheme: CustomFlowbiteTheme["navbar"] = { link: { base: "block py-2 pl-3 pr-4 md:p-0 border-b border-neutral-200 md:border-transparent", active: { - on: "bg-neutral-200 rounded text-white md:bg-transparent md:text-neutral-800 font-semibold text-accent-900", - off: "text-neutral-700 hover:bg-neutral-100 transition transform duration-50 hover:text-neutral-800 md:hover:bg-transparent md:hover:border-b-2 md:hover:border-neutral-600", + on: "bg-neutral-200 rounded text-white md:bg-transparent text-primary-450 font-semibold", + off: "text-neutral-700 hover:text-primary-450 hover:bg-neutral-100 transition transform duration-50 md:hover:bg-transparent md:hover:border-b-2 md:hover:border-primary-450", }, disabled: { on: "text-neutral-400 hover:cursor-not-allowed", @@ -97,7 +97,7 @@ const dropdownTheme: CustomFlowbiteTheme["dropdown"] = { target: "w-fit", }, inlineWrapper: - "flex items-center py-2 pl-3 pr-4 md:p-0 text-neutral-700 hover:text-neutral-800 md:border-transparent md:border-b-2 md:hover:border-neutral-600 duration-50 transition transform", + "flex items-center py-2 pl-3 pr-4 md:p-0 text-neutral-700 hover:text-primary-450 md:border-transparent md:border-b-2 md:hover:border-primary-450 duration-50 transition transform", }; function NavbarLink({ @@ -193,7 +193,7 @@ export default function RootNavbar() { Sign in @@ -201,7 +201,7 @@ export default function RootNavbar() {
Sign up diff --git a/website/src/components/Sidebar/index.tsx b/website/src/components/Sidebar/index.tsx index ab8e61911..4e38d8bdb 100644 --- a/website/src/components/Sidebar/index.tsx +++ b/website/src/components/Sidebar/index.tsx @@ -6,6 +6,12 @@ import { Sidebar as FlowbiteSidebar } from "flowbite-react"; import Link from "next/link"; import { useDrawer } from "@/components/Providers/DrawerProvider"; +const ItemGroupLabelTheme: CustomFlowbiteTheme["sidebar"] = { + item: { + base: "flex items-center justify-center rounded p-2 text-sm font-semibold uppercase text-primary-450", + }, +}; + const FlowbiteSidebarTheme: CustomFlowbiteTheme["sidebar"] = { root: { base: "h-[calc(100vh)] left-0 top-0 z-40 sticky bg-white transition-transform pt-16 pb-8", @@ -121,8 +127,23 @@ export function SidebarItems({ children }: { children: React.ReactNode }) { return {children}; } -export function SidebarItemGroup({ children }: { children: React.ReactNode }) { - return {children}; +export function SidebarItemGroup({ + label, + children, +}: { + label?: string; + children: React.ReactNode; +}) { + return ( + + {label && ( + + {label} + + )} + {children} + + ); } export function SidebarCollapse({