Resources

Resources define subnets, IP addresses, DNS names, or sets of Clients you wish to manage access for.

To create a Resource, open Resources in the left sidebar and click New Resource.

From there, you can select the type of Resource you want to create:

• DNS: A domain name pattern to match.
  • By default, the pattern will only match the exact name you enter.
  • To match all subdomains recursively, use a double-wildcard, such as **.example.com. This will match example.com, sub.example.com, and sub.sub.example.com.
  • To match all subdomains non-recursively, use a single wildcard, such as *.example.com. This will match sub.example.com but not sub.sub.example.com.
  • To match a single character, use a question mark, such as us-east?.example.com. This will match us-east1.example.com but not us-eastXY.example.com.
  • Wildcards can be placed between domain components, e.g., foo.*.example.com will match foo.bar.example.com or foo.**.example.com will match foo.bar.baz.example.com.
• IP: A single IPv4 or IPv6 address
• CIDR: A range of IPv4 or IPv6 addresses in CIDR notation, such as 10.1.2.0/24 or 2001:db8::/48
• Device Pool: A set of Clients, reachable peer-to-peer without a Gateway. See Device Pools.

Routing order for overlapping addresses

When multiple Resources' addresses overlap, the Resource with the more specific address will be used.

For CIDR Resources, an address with a longer prefix is more specific than a shorter one. For example: 10.0.0.0/16 is more specific than 10.0.0.0/8. IP Resources are essentially addresses with /32 prefix and thus always more specific than any other CIDR.

For DNS Resources, more specific loosely translates to less wildcards. In particular:

• Resources without wildcards are always prioritized over wildcard domains: For example, app.example.com is checked before *.example.com.
• Single-char wildcards (?) take priority over label wildcards (*): For example, ???.example.com is checked before *.example.com.
• Label wildcards (*) take priority over catch-all wildcards (**): For example, *.example.com is checked before **.example.com.

Address description

When creating a Resource, the Resource form includes an optional address_description field. If given, this will be displayed in the Client's Resource list to help identify the Resource. If a URL is entered, it will be displayed as a clickable link.

This is commonly used to show a different address to end users than the one used for routing, where field validations are more restrictive. This can be useful to provide a bookmark to a service like https://gitlab.company.com, or give hints for accessing the service, like 10.0.0.1:2222.

IP stack

The IP stack setting for DNS Resources controls the types of DNS records (A for IPv4, AAAA for IPv6) generated by the stub resolver.

• Dual-stack (Default): Generates both A and AAAA records.
• IPv4 only: Generates only A records.
• IPv6 only: Generates only AAAA records.

This setting primarily enhances compatibility with applications that might not properly handle ICMP unreachable errors. These errors are typically sent by the Gateway to indicate that the requested IP stack (e.g., IPv6) does not have corresponding A or AAAA records for a connection attempt.

Since some applications don't gracefully handle these errors, configuring the IP stack to IPv4 only or IPv6 only can mitigate such issues by ensuring only available records are returned.

If you're unsure, it's generally recommended to leave this setting at Dual-stack.

Traffic restrictions

In the Traffic restrictions section of the Resource form, you can specify optional port range(s) and protocols on the Resource for finer access control, useful for restricting certain services while allowing others. Supported protocols currently include ICMP, TCP, and UDP.

One popular use case for traffic restrictions is segmenting access to individual services on a host. To do this, simply create a Resource for each service on the host you want to allow access to, and add the appropriate traffic restrictions to each one.

For example, create an Resource with the TCP/22 restriction to allow SSH access for your DevOps team, then add another Resource with the TCP/443 restriction to allow access to an HTTPS service for the rest of your organization.

Device Pools

A Device Pool lets you give people access to devices wherever they are: help a colleague over remote desktop, SSH into a development machine, or reach your laptop from your phone. Install and sign in to the Firezone Client on both ends, choose which devices belong in the pool, and grant access with a Policy.

You don't need to deploy a Gateway, give the destination a public IP address, or configure inbound access on your network firewall. Firezone connects the Clients over an encrypted WireGuard tunnel, even when they are on different networks. A Device Pool does not belong to a Site.

Choose which devices belong in the pool

Choose one of four Pool membership criteria when creating the Resource:

The first three choices follow device ownership and Group membership, so you don't have to maintain a list of individual machines. With Static list, you add and remove devices yourself.

Membership and access are separate

Membership chooses the destination devices. A Policy grants a Group access to those devices. For example, a pool containing the Engineering Group's devices can have a Policy granting access to the Support Group. Engineering owns the destinations; Support gets permission to connect.

For Your devices, the destinations depend on who is connecting. A Policy for the Everyone Group lets each user reach their own devices, without giving them access to everyone else's.

Access is one-directional: adding a device to a pool does not grant it access to other members. The device's owner is not asked to approve incoming connections, so choose membership and Policies with the same care as any other grant of access.

Traffic restrictions let you limit access to the services people need. For example, allow TCP port 22 for SSH or TCP port 3389 for RDP. Firezone controls network access; users still authenticate to SSH, RDP, or the application running on the destination device.

Addressing a pool member

Each device has its own DNS name in the form <slug>.firezone.network. Use this name in your SSH configuration, remote desktop app, or browser instead of remembering an IP address. For example, a device with the slug alice-laptop is reachable as alice-laptop.firezone.network:

# Open an SSH session
ssh alice@alice-laptop.firezone.network

# Reach a dev server on port 3000
curl http://alice-laptop.firezone.network:3000

You can copy the full DNS name from the Slug field in the device's details in the admin portal. To change it, edit the device's Slug. Slugs must be unique within your account and contain 1–63 lowercase letters, digits, or hyphens, beginning and ending with a letter or digit. Changing a slug changes the DNS name, so update any saved connections that use it.

The name identifies a device, not the pool. Firezone resolves it for Clients with access to that device through a Device Pool; knowing the name does not grant access.

You can also connect using the device's stable tunnel IPv4 or tunnel IPv6 address, shown in the pool's Pool Members tab. For example, ssh alice@100.96.0.24 reaches a device with that tunnel IPv4 address.

How Clients reach each other

Firezone automatically establishes a direct connection using hole-punching and NAT traversal. If the network prevents a direct connection, traffic falls back to a relay and remains encrypted between the two Clients.

Each Client has stable tunnel addresses from Firezone's reserved ranges: 100.64.0.0/10 for IPv4 and fd00:2021:1111::/48 for IPv6. These identify the device independently of the network it is on. Device Pools do not take part in the routing order for address-based Resources.

Device Pool requirements

Both Clients in a connection must be new enough to support Device Pools. See the versions listed at the top of this section.

Two Clients also need to be on the same major and minor version to connect to each other. A Client on 1.5.x can reach any other Client on 1.5.x, but not one on 1.6.x. Plan upgrades for both ends together so people can keep reaching the devices they need. Connections across that version boundary will fail until both ends are on the same major and minor version.

Finally, a pool member has to be online. Firezone cannot wake a machine that is asleep or disconnected, and connections to an offline member will fail. The Pool Members tab shows which members are currently online.

For the steps to build a pool and connect to one, see Access a device via SSH or RDP.

The Internet Resource

The Internet Resource is a special Resource available on paid plans that allows you to route 0.0.0.0/0 and ::/0 through Firezone in a full-tunnel configuration. It functions as a fallback for traffic that doesn't match any other Resource.

When Client traffic matches a DNS, IP, or CIDR Resource, that more-specific Resource takes priority over the Internet Resource and uses a Gateway serving its Site. This allows private Resources to remain reachable without allowing Internet Gateways to serve them.

The Internet Resource is automatically enabled on Team and Enterprise plans. To use it, head to the main Sites section in the admin portal, and look for the Manage Internet Resource in the section at the bottom of the page.

This will take you to the Internet Site, a special system-managed Site dedicated to hosting the Internet Resource. Here you can deploy Gateways and manage Policies like any other Site.

About Gateways serving the Internet Resource

Gateways deployed to the Internet Site serve only the Internet Resource. They are kept separate from Gateways that serve DNS, IP, and CIDR Resources so that access to the Internet Resource cannot grant access to private Resources reachable from the Gateway.

The Internet Resource does not route traffic to the following address ranges:

• Private IPv4 addresses defined by RFC 1918 (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16)
• Unique local IPv6 addresses defined by RFC 4193 (fc00::/7)
• IPv4 and IPv6 link-local addresses (169.254.0.0/16 and fe80::/10), including cloud instance metadata services such as 169.254.169.254
• IPv4-compatible, IPv4-mapped, and IPv4-translated IPv6 address formats, which are not public Internet destinations
• Deprecated IPv6 site-local addresses (fec0::/10)
• The shared address space used for carrier-grade NAT (100.64.0.0/10)
• IPv4 addresses reserved for future use (240.0.0.0/4)
• Firezone's internal IPv4 and IPv6 tunnel and Resource address ranges

Gateways serving the Internet Resource reject traffic to or from these ranges. This restriction does not apply to Gateways that do not serve the Internet Resource.

Need help? See all support options.