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 is a Resource made up of Clients instead of an address. When you grant a Group access to one, people in that Group connect directly to the Clients in the pool.

The connection is peer-to-peer. Traffic goes straight from one Client to the other over an encrypted WireGuard tunnel. There is no Gateway in the middle, and the machine you are reaching does not need a public IP address or any inbound firewall rules. This is what makes Device Pools useful for the things that are awkward to put behind a Gateway: SSH into a coworker's laptop, reach a dev server on your own machine from your phone, or give a support team access to a fleet of kiosks.

Because a Device Pool has no address, it does not belong to a Site and does not take part in the routing order above.

How Clients reach each other

Every Firezone Client is assigned a stable tunnel address when it first connects: one IPv4 address and one IPv6 address that belong to the Client and do not change. They come out of Firezone's reserved ranges, 100.64.0.0/10 for IPv4 and fd00:2021:1111::/48 for IPv6.

When a Client tries to reach a tunnel address belonging to a pool member, the two Clients negotiate a direct tunnel using the same hole-punching and NAT traversal that Clients already use to reach Gateways. Firezone's signaling servers help the two ends find each other, then step out of the way. If a direct path really cannot be established, the connection falls back to a relay.

Addressing a pool member

You reach a pool member by its tunnel IP. Firezone does not assign it a DNS name, so use the address directly. Say a teammate's laptop has the tunnel addresses 100.96.0.24 and fd00:2021:1111::24, and it is a member of a pool you have access to:

# SSH over IPv4
ssh alice@100.96.0.24

# SSH over IPv6
ssh alice@fd00:2021:1111::24

# A dev server on port 3000
curl http://100.96.0.24:3000

# Ping it
ping 100.96.0.24

Tunnel addresses are stable, so they can go in an SSH config or a bookmark and keep working. The admin portal shows both addresses for every member of a pool.

Traffic restrictions apply to Device Pools like any other Resource. For pools built out of people's working machines this is worth using: a TCP/22 restriction grants exactly SSH rather than the whole machine.

Membership and access are separate

Membership decides which machines can be reached. Policies decide who can reach them. They are two different lists, and a Client can be on either one without being on the other.

A Client that is a member of a pool is reachable by everyone whose Group has a Policy for that pool. The member's owner is not asked to approve the connection and is not notified when one happens. Adding someone's laptop to a pool is an administrative decision, so treat pool membership the way you would treat any other grant of access to a machine.

Access is also one-directional. Putting a laptop in a pool does not give that laptop access to anything. If you want the members to reach each other, add a Policy granting the members' own Group access to the pool.

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. This lets Firezone evolve the peer-to-peer wire format between minor releases. In practice it means that during an upgrade, connections between Clients on either side of the version boundary will not establish until both ends have been upgraded.

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.