Deploy Gateways

Gateways are what Clients connect to in order to access Resources in a Site. They're the data plane workhorse of the Firezone architecture and are responsible for securely routing traffic between Clients and Resources.

Prerequisites

• iptables and/or ip6tables
• Any Linux distribution with kernel 3.10 or later
• Docker Engine (for docker-based installs)
• Systemd (for systemd-based installs)

Firewall considerations

Gateways implement the industry-standard STUN and TURN protocols to securely perform NAT holepunching. No ingress firewall ports are required for Gateways to function.

If the network in which your Gateway is deployed performs egress filtering, you'll need to make sure the following outbound traffic is allowed:

Where to deploy Gateways

Ideally, Gateways should be deployed as close to the Resources they're serving -- in some cases, even on the same physical host. This ensures the lowest possible latency and highest possible throughput for Client connections, and allows you to more easily deploy additional Gateways for a particular Resource that needs to handle more Client connections.

The downside of deploying Gateways close to Resources is that it increases the number of overall Gateways you need to deploy, possibly making it more difficult to manage and monitor them. Firezone's control plane is designed to make this as easy as possible, but it's still something to keep in mind when planning your deployment.

Deploy a single Gateway

Deploying a single Gateway can be accomplished in the admin portal.

Go to Sites -> <name of Site> -> Deploy a Gateway and follow the prompts to deploy for your preferred environment. This will deploy a single Gateway.

See the upgrading guide for information on keeping your Gateway up-to-date.

Deploy multiple Gateways

To achieve high availability, deploy more Gateways within the same site.

You can deploy multiple Gateways from the admin portal, or automate the process by reusing the FIREZONE_TOKEN environment variable shown when deploying a Gateway from the admin portal.

When deploying a Gateway from the admin portal, a FIREZONE_TOKEN environment variable is shown. This variable can be reused to deploy multiple Gateways within the same Site.

This means you can automate deployment of the Gateway using your automation method of choice, adding as many Gateways as necessary for failover and load balancing.

Deploy using Terraform

See our Terraform examples for deploying and scaling Gateways on Google Cloud Platform.

High availability

Firezone was designed from the ground up to support high availability requirements. This is achieved through a combination of automatic failover and load balancing, both of which are automatically enabled on all plans.

Automatic failover

Two or more Gateways can be deployed within a Site to achieve automatic failover for Client connections to Resources in that Site.

Here's how it works:

• When the admin portal detects a particular Gateway is unhealthy, it will stop using it for new connection requests to Resources in the Site.
• Existing Clients will remain connected to the Gateway until they themselves detect it to be unhealthy.
• Clients identify unhealthy gateways using keepalive timers. If the timer expires, the Client will disconnect from the unhealthy Gateway and request a new, healthy one from the portal.
• The Client keepalive timer expires after 20 seconds. This is the maximum time it takes for existing Client connections to be rerouted to a healthy Gateway in the event of a Gateway failure.

By using two independent health checks in the portal and the Client, Firezone ensures that temporary network issues between the Client and portal do not interrupt existing connections to healthy Gateways.

Load balancing

Similar to automatic failover, two or more Gateways deployed within a Site will automatic load balance Client connections to Resources in that Site.

When a Client wants to connect to a Resource, Firezone randomly selects a healthy Gateway in the Site to handle the request. The Client maintains the connection to that Gateway until either the Client disconnects or the Gateway becomes unhealthy.

Deploy as many Gateways as you need to handle the load of Client connections to Resources in a Site. This effectively shards Client connections across all Gateways in a Site, achieving higher overall throughput than otherwise possible with a single Gateway.