Resources
A practical guide for configuring network resources secured via Twingate.
A Resource can be any network address that you wish users to access via Twingate. The only requirement is that the network address be resolvable and routable from the Connector(s) deployed in the Resource’s Remote Network (see How DNS Works with Twingate for more detail). The most common scenarios are:
- Private Resources, private DNS
Adding a private DNS Resource such as
host.autoco.internal, or*.autoco.internalfor a wildcard range, will make it accessible to authorized Twingate users without changing your DNS configuration or making name resolution public. - Private Resource, private IP or CIDR-defined subnet Similar to above, this is any private IP or CIDR range. The address does not need to be routable from the end user’s device.
- IP whitelisting for public destinations You may want to IP-whitelist traffic to public destination such as SaaS services. When running the Twingate client, user traffic for a public address Resource will first be routed to the configured Connector before exiting to the public destination. This use case is covered in more detail in Whitelisting Traffic to Public Resources.
Resource Definition
A Resource is defined by several characteristics:
A label
A Resource’s label is its name. The label will be displayed both in the Admin Console and in the Client.
An address
Which can be one of the following:
- A Fully Qualified Domain Name (FQDN), eg.
host.autoco.internal - An FQDN using one or more wildcards, eg.
*.host-0?.autoco.internal, where*represents 0 or more characters and?represents exactly 1 character.- Wildcards like
*.autoco.internalmatch anything to the left of.autoco.internal, includinghost.autoco.internal,longerhost.autoco.internalandsub.host.autoco.internal, but will not matchautoco.internalitself.
- Wildcards like
- An IP address, eg.
10.1.0.35 - A valid IP CIDR range, eg.
10.1.0.0/16. Invalid IP CIDR range definitions, eg.10.1.0.1/16or10.1.0.16/16, will return the errorInvalid IP or FQDN. - Unqualified DNS name (eg.
host), are supported, but require some additional Connector configuration and use of the latest Twingate Client application.
A Resource's configured address
The configured address of the Resource is that as resolved from the Connector(s) in the associated Remote network. See the section on Address Resolution of Resources for more detail.
An alias
Aliases enable Resources to be reached by an extra address. Users can access both the address and the alias.
Port restrictions
Which ports are allowed, defaulting to all TCP and UDP ports. You may configure port restrictions on individual resources of any address type.
Ports or protocols are not required when defining a Resource. By default, Twingate will forward traffic for any UDP or TCP protocol, including ping requests via ICMP. This means that users can access Resources via their web browser, SSH, VNC or RDP without any special configuration on their devices or at the remote application.
A Remote Network
This is the Remote Network you associate the Resource with when configuring it.
The Resource must be reachable over the local network from the installed Connector(s) on the Remote network.
Client visibility
Whether a Resource is visible in the Client and whether it will have a browser shortcut. Read more on hiding resources in the client.
Address Resolution of Resources
Is your Resource a private or internal IP address?
Due to DNS rebind protection that is increasingly common, we strongly recommend that any DNS address that resolves to a private or internal IP address be defined as a DNS Resource within Twingate so that it can be routed correctly and resolved at the Connector.
For example, if host.domain.com can be resolved publicly to a private IP address such as 10.0.1.10, you should take one of the following approaches:
- Define the Resource as
host.domain.comin Twingate. This ensures that the Connector will perform the name resolution, which will correctly route users’ traffic. - Use private DNS resolution instead, defining the IP address for
host.domain.comusing private DNS on your Remote Network. - Define the Resource using its private IP address,
10.0.1.10. This will also route user traffic, but loses the advantage of using DNS naming entirely.
Address resolution of Resources is performed from the Connector(s) on the Remote network that a particular Resource is associated with. This means that both local IP addresses and local (private) DNS names will resolve for remote users connected to Twingate.
For example, a Connector that can resolve any host on the autoco.internal domain will allow resolution of a Resource with the address host.autoco.internal from the Twingate client with no additional configuration. When a user authorized to access this Resource is connected to Twingate, they access it by connecting to host.autoco.internal on their local device, as if they were directly connected to the remote network.
For a more detailed description, see How DNS Works with Twingate.
Twingate denies traffic by default, following Zero Trust principles
If a user has not explicitly been given access to a Resource, they will not be able to connect to it, with network connection requests denied from the user’s endpoint device.
Aliases
Resources are also resolved by their alias, if they have one. You don’t need to set up DNS entries for an alias. Aliases are resolved by the Connect and do not require the alias address to actually be resolvable on the Connector’s side.
For more details, read the documentation on Resource aliases.
Port Restrictions
Port restrictions on resources require that all Connectors on your Remote network be v1.20.0 or higher. If this is not the case, port restriction configuration will not be available. See Upgrading Connectors.
By default, both TCP and UDP traffic on any port and ping requests over ICMP are forwarded to any defined Resource. You may add a port restriction on any Resource, even wildcard or CIDR ranges, as long as you meet the Connector version requirements for the Remote network listed above.
There are two primary use cases for adding port restrictions:
- Limiting traffic to only necessary ports for all users. This is valuable where setting internal firewall rules for individual destination hosts is difficult or impossible.
- Separating which users are allowed to access a single Resource on different ports. For example, you may want to allow all users to access a web resource on TCP port 443, but only provide a small subset of users access to TCP port 22 for SSH access. You can achieve this by creating two separate Resources in Twingate (eg.
host.autoco.internal:22andhost.autoco.internal:443) and assigning them to different user groups.
- Port restrictions can be applied to TCP and UDP separately. For example, you can allow ports 22 and 443 for TCP and port 53 for UDP without allowing any extra TCP or UDP ports.
- ICMP can be toggled to be enabled or blocked.
Hiding Resources in the Client
Resource visibility settings are only available on the following client versions:
- macOS 1.0.25 and higher
- Windows 1.0.23 and higher
- iOS 1.0.25 and higher
- Android 1.0.22 and higher
- Linux 1.0.74 and higher
By default, all resources a user has access to will show up in the Client. You may hide individual resources in the Admin Console. This may be useful to reduce user confusion by hiding Resources that users are unlikely to interact with. Further, you can enable the Client’s “Open in Browser” shortcut so your users can easily open Resources if they’re meant to be viewed in a browser.
These settings do not affect visibility in the Admin Console.
Resource visibility options are one of the following:
- Standard Address: The Resource will be visible in the main list of Resources in the Client.
- Browser Address: The Resource will be visible in the main list of Resources in the Client and will have a shortcut to open the Resource in the browser.
- Background Address: The Resource will only be visible in the “Background Resources” section in the Client.
Last updated 2 months ago