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.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 three 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.
    • Wildcards like *.autoco.internal match anything to the left of .autoco.internal, including host.autoco.internal, longerhost.autoco.internal and, but will not match autoco.internal itself.
  • An IP address, eg.
  • An IP CIDR range, eg.
  • 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. Its Remote network

This is the Remote Network you associate the Resource with when configuring it.

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

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.

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:22 and host.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, as well as toggle the “Open in Browser” shortcut. These options are useful to reduce user confusion by hiding resources that users are unlikely to interact with and disabling “Open in Browser” for resources that cannot be opened in a browser.

If the “Visible in the Main Resource List” option is enabled, then the resource will appear in the main list of resources in the client. Likewise, disabling this option will move the resource to the “Background Resources” section in the client. This option does not affect visibility in the Admin Console.

If the “Browser Shortcut” option is enabled, then the client will have a shortcut to open the resource in the browser. If disabled, no shortcut will appear.

Last updated 2 days ago