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.combut 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/24or2001:db8::/48
Note: 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.