Create Resources
Resources define subnets, IP addresses, or DNS names you wish to manage access for.
To create a Resource, go to Sites -> <site name> -> Add a Resource
.
Remember, Resources must be reachable by all Gateways in the same Site.
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 exactly the name you enter.
- To recursively match all subdomains, use a wildcard, such as
*.example.com
. This will matchexample.com
,sub2.example.com
, andsub1.sub2.example.com
. - To non-recursively match all subdomains, use a question mark, such as
?.example.com
. This will matchexample.com
,sub1.example.com
, andsub2.example.com
but notsub1.sub2.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
or2001:db8::/48
Note: To preserve audit trails, once a Resource is created, its address cannot be changed. Double-check to ensure the address entered is correct before creating the Resource.
Address description
When creating a Resource, you'll be given the option to add an
address_description
. 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
.
Traffic restrictions

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.
Need additional help?
See all support options or try asking on one of our community-powered support channels:
- Discussion forums: Ask questions, report bugs, and suggest features.
- Discord server: Join discussions, meet other users, and chat with the Firezone team
- Email us: We read every message.