Ports and Protocols in Use

This reference lists the firewall ports, outbound destinations, and host permissions Firezone needs. Both Clients and Gateways rely on the same outbound connectivity — Firezone establishes outbound-only connections, so in the common case there are no inbound ports to open (see the FAQ). For install steps, see Deploy Gateways and Install the Client.

Firezone implements the industry-standard STUN and TURN protocols to perform secure NAT holepunching. This lets Clients and Gateways establish direct connections to each other while keeping your Resources invisible to the public internet.

Outbound ports

Both Clients and Gateways need outbound access to the destinations below. If the network they run in applies egress filtering, allow the following:

HostIP AddressPort(s)Protocol(s)Purpose
app.firezone.dev132.164.158.66, 20.227.85.249, 4.249.162.238, see portal-ips.json443HTTPSAuthentication and admin portal access (IPv4)
app.firezone.dev2603:1010:3:d::95, 2603:1020:0:1c::26, 2603:1030:b:25::37, see portal-ips.json443HTTPSAuthentication and admin portal access (IPv6)
api.firezone.dev132.164.158.66, 20.227.85.249, 4.249.162.238, see portal-ips.json443HTTPS/WebSocketControl plane API (IPv4)
api.firezone.dev2603:1010:3:d::95, 2603:1020:0:1c::26, 2603:1030:b:25::37, see portal-ips.json443HTTPS/WebSocketControl plane API (IPv6)
flow-api.firezone.dev4.249.162.238, see portal-ips.json443HTTPSFlow log ingest API (IPv4)
flow-api.firezone.dev2603:1030:b:25::37, see portal-ips.json443HTTPSFlow log ingest API (IPv6)
sentry.firezone.devVaries, see Azure Front Door IP ranges443HTTPSCrash reporting / telemetry
posthog.firezone.devVaries, see Azure Front Door IP ranges443HTTPSFeature-flag evaluation
N/AVaries, see relay-ips.json3478STUNSTUN protocol signaling
N/AVaries, see relay-ips.json49152-65535TURNTURN protocol channel data
github.com, www.firezone.devVaries443HTTPSGateways only — required for Gateway upgrades

Gateways and the headless Linux and Windows Clients can opt out of crash reporting and telemetry by setting FIREZONE_NO_TELEMETRY=true (or passing --no-telemetry); see the Gateway CLI reference for Gateways. The GUI and mobile Clients don't currently support opting out.

Inbound ports

In most cases, no inbound firewall ports are needed — Clients and Gateways both initiate their connections outbound. If a stateless firewall sits in front of a Client or Gateway, however, you'll need to allow UDP return traffic so the two can connect directly; otherwise connections fall back to a relay. The table below covers the common cloud environments where Gateways run; the same principle applies to any Client network with a stateless firewall.

ProviderResource typeTypeInbound ports
AWSNetwork ACLsStatelessBy default, AWS ACLs allow all inbound. If you've modified these, be sure that UDP 1024-65536 is allowed from source 0.0.0.0/0 so your Clients can connect directly. If you wish to allow only Relayed connections, use the source IPs in relay-ips.json.
AWSSecurity GroupsStatefulNone
AzureNetwork Security GroupsStatefulNone
GCPFirewall RulesStatefulNone

Gateway host permissions

In order to function correctly, Gateways need access to several parts of the Linux system:

  1. The TUN device as /dev/net/tun
  2. Permissions to open new UDP sockets
  3. Permissions to add and remove routes via netlink

Typically, it is enough to run Gateways with the CAP_NET_ADMIN capability. Alternatively, you can run them as root.

Gateways check on startup for these conditions and fail if they aren't met. You can skip these permission checks by passing --no-check. This is only advisable if you have configured access in ways not covered by these checks.

Clients also use a TUN device, but the per-platform Client installers configure the necessary permissions for you — see Install the Client.


Need help? See all support options.

Found a problem with this page? Open an issue
Last updated: July 01, 2026