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/orip6tables
- 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:
Host | (IP Address) | Port(s) | Protocol(s) | Purpose |
---|---|---|---|---|
api.firezone.dev | 34.102.202.25 | 443 | HTTPS/WebSocket | Control Plane API (IPv4) |
api.firezone.dev | 2600:1901:0:620b:: | 443 | HTTPS/WebSocket | Control Plane API (IPv6) |
N/A | Varies | 3478 | STUN | STUN protocol signaling |
N/A | Varies | 49152 - 65535 | TURN | TURN protocol channel data |
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.
When deploying Gateways, remember that all Gateways and Resources in a Site must have unobstructed network connectivity to each other. This is necessary for Firezone's automatic failover and load balancing features to work correctly.
Sizing recommendations
Gateways, like the rest of Firezone's data plane stack, are written in Rust and are thus Resource efficient by nature.
A single Client connection to a single Gateway can typically reach speeds of 1 Gbps or more. This scales linearly with each Client connection up to the number of CPU cores available to the Gateway.
Use the table below as a rough guide for sizing your Gateway deployments:
Gateway size | Users served | CPU cores | Memory | Network link |
---|---|---|---|---|
Small | 100 | 2 | 2 GB | 1 Gbps |
Medium | 1,000 | 8 | 8 GB | 10 Gbps |
Large | 10,000 | 32 | 32 GB | 40 Gbps |
To go beyond the table above, you can deploy additional Gateways and use Firezone's automatic load balancing to distribute Client connections across them.
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.
Note: Be sure to set a unique FIREZONE_ID
for each Gateway you deploy.
This can be any non-empty string and is used to identify the Gateway in the
portal for audit trail and logging purposes.
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.
Need additional help?
Try asking on one of our community-powered support channels:
- Discussion forums: Ask questions, report bugs, and suggest features.
- Public Slack group: join discussions, meet other users, and meet the contributors