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 endpoints for the account’s cloud, followed by the shared destinations below. EU accounts use separate authentication, control-plane, and flow-log ingest hosts.
Firezone Cloud US
| Host | IP Address | Port(s) | Protocol(s) | Purpose |
|---|---|---|---|---|
| app.firezone.dev | 4.148.135.86, 4.249.162.238, see portal-ips.json | 443 | HTTPS | Authentication and admin portal access (IPv4) |
| app.firezone.dev | 2603:1030:501:10::1e2, 2603:1030:b:25::37, see portal-ips.json | 443 | HTTPS | Authentication and admin portal access (IPv6) |
| api.firezone.dev | 4.148.135.86, 4.249.162.238, see portal-ips.json | 443 | HTTPS/WebSocket | Control plane API (IPv4) |
| api.firezone.dev | 2603:1030:501:10::1e2, 2603:1030:b:25::37, see portal-ips.json | 443 | HTTPS/WebSocket | Control plane API (IPv6) |
| flow-api.firezone.dev | 4.249.162.238, see portal-ips.json | 443 | HTTPS | Flow log ingest API (IPv4) |
| flow-api.firezone.dev | 2603:1030:b:25::37, see portal-ips.json | 443 | HTTPS | Flow log ingest API (IPv6) |
Firezone Cloud EU
| Host | IP addresses | Port | Protocol | Purpose |
|---|---|---|---|---|
| eu.app.firezone.dev | 172.189.107.45, 57.174.44.173, see portal-ips.json | 443 | HTTPS | Authentication and admin portal (IPv4) |
| eu.app.firezone.dev | 2603:1020:1001:26::329, 2603:1020:802:7::86, see portal-ips.json | 443 | HTTPS | Authentication and admin portal (IPv6) |
| eu.api.firezone.dev | 172.189.107.45, 57.174.44.173, see portal-ips.json | 443 | HTTPS/WebSocket | Control plane (IPv4) |
| eu.api.firezone.dev | 2603:1020:1001:26::329, 2603:1020:802:7::86, see portal-ips.json | 443 | HTTPS/WebSocket | Control plane (IPv6) |
| eu.flow-api.firezone.dev | 57.174.44.173, see portal-ips.json | 443 | HTTPS | Flow log ingest (IPv4) |
| eu.flow-api.firezone.dev | 2603:1020:1001:26::329, see portal-ips.json | 443 | HTTPS | Flow log ingest (IPv6) |
Automation that uses the REST API or MCP also needs outbound HTTPS on port
443 to rest-api.firezone.dev (US) or eu.rest-api.firezone.dev (EU).
Shared destinations
Both clouds use the services and protocols below.
EU accounts also use global services. Relays can be outside the EU and forward encrypted traffic; diagnostics use US subprocessors. See the Relay locations and US processing reference when reviewing network egress and data handling.
| Host | IP Address | Port(s) | Protocol(s) | Purpose |
|---|---|---|---|---|
| sentry.firezone.dev | Varies, see Azure Front Door IP ranges | 443 | HTTPS | Crash reporting / telemetry |
| posthog.firezone.dev | Varies, see Azure Front Door IP ranges | 443 | HTTPS | Feature-flag evaluation |
| N/A | Varies, see relay-ips.json | 3478 | STUN | STUN protocol signaling |
| N/A | Varies, see relay-ips.json | 49152-65535 | TURN | TURN protocol channel data |
| N/A | Client or Gateway IPs for direct connections; Relay IPs for relayed connections | Varies | WireGuard (UDP) | Encrypted traffic between Clients and Gateways, directly or through Relays |
| github.com, www.firezone.dev | Varies | 443 | HTTPS | Gateways 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.
| Provider | Resource type | Type | Inbound ports |
|---|---|---|---|
| AWS | Network ACLs | Stateless | By 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. |
| AWS | Security Groups | Stateful | None |
| Azure | Network Security Groups | Stateful | None |
| GCP | Firewall Rules | Stateful | None |
Gateway host permissions
In order to function correctly, Gateways need access to several parts of the Linux system:
- The TUN device as
/dev/net/tun - Permissions to open new UDP sockets
- 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.