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.internal for 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 two characteristics:

1. Its 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.
• An IP address, eg. 10.1.0.35
• An IP CIDR range, eg. 10.1.0.0/16
• Unqualified DNS name (eg. host), are supported, but require some additional Connector configuration and use of the latest Twingate Client application.

2. Allowed ports, which default to allowed on all TCP and UDP ports. You may configure port restrictions on individual resources of any address type.
3. The Remote network you associate the Resource with when configuring it.

Note: 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.

Note: the Resource must be reachable over the local network from the installed Connector(s) on the Remote network.

By default, Twingate will forward traffic for any UDP or TCP protocol, including ping requests via ICMP, so ports or protocols are not required when defining a Resource. 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.

Address Resolution of Resources

🚧

Avoid using a public DNS service to resolve private IP addresses

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.com in 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.com using 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.

Note: 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.

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:

1. 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.
2. 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 port 443, but only provide a small subset of users access to port 22 for SSH access. You can achieve this by creating two separate Resources in Twingate (eg. host.autoco.internal:22 and host.autoco.internal:443) and assigning them to different user groups.

• Port restrictions currently apply to both TCP and UDP. For example, defining a port restriction of 80,443 will allow traffic to the Resource on ports 80 and 443 via both TCP and UDP transports.
• ICMP is currently enabled by default.
• Transport-specific controls can be enabled via our API. Port restrictions can be specified separately for TCP and UDP, and ICMP forwarding may also be toggled.