Best Practices for Overlapping IP Addresses
Let's explore what to do in Twingate when two or more resources have the same IP address.
What is IP overlap and why it happens
IP overlap refers to 2 or more assets existing in different network subnets and using the same IP address.
This situation can sometimes create ambiguity when mapping Twingate Resources to Groups. Let’s use the following hypothetical scenario:
At Autoco, the SQL database in the development environment is in its own subnet but it uses the same IP address (
10.1.2.4) as its production counterpart. The same is true for the Application Server instances in both environments: they are separate servers but use the same IP address of
What about the Fileshare server?
The fileshare server has a different IP address for development (
10.1.2.5) and production (
10.1.2.6). Therefore, we can easily create 2 separate Twingate Resources, one for each server and map them to the right Remote Networks.
As a reminder, in Twingate, Resources are attached to Remote Networks and are assigned to User Groups. This is because we want connection requests to any Resource to be as simple as possible for the end users: when they connect to a particular IP address or FQDN, Twingate figures out which Remote Network (and Connectors) to use to serve the connection request - the end user never needs to figure this out.
Why it creates ambiguity
If all Twingate users in a particular Group require access to a Twingate Resource pointing to
10.1.2.4 in both production and development, it creates an ambiguity for Twingate as it will not be able to determine automatically which Remote Network to use.
Let’s resolve this by diving deeper into the two typical options at our disposal. Neither option involves restructuring networks or changing IP addresses, which we know can require significant effort.
Option 1: Use a private DNS server
The first (and in our opinion, best) option is to deploy a private DNS server with specific DNS zones to address each subnet containing IP-overlapping resources that needs to be served via Twingate.
In this case, the correct naming convention can resolve the ambiguity and bring an additional layer of visibility for end users over what environment they are connecting to:
We can create 2 DNS zones, one for each subnet:
*.dev.autoco.comwill be used for all assets in the development environment
*.prod.autoco.comwill be used for all assets in the production environment
In this implementation, each DNS zone would have multiple DNS records pointing to the assets containing overlapping IP addresses, for example:
We would then reconfigure Twingate Resources away from IP address-style Resources and simply use the new FQDNs.
Once this is in place, when an end user connects to
server.dev.autoco.com, Twingate will automatically route them to the
development Remote Network, removing the ambiguity while allowing the network configuration to remain unchanged.
Option 2: Map Users to Groups and Resources without ambiguity
Technically speaking, you can still create two separate Resources in Twingate with the same IP address, but assign each Resource to a different Remote Network:
What to remember
As long as no Twingate User belongs to 2 or more groups that are themselves attached to identical IP address-style Resources, you will not create any ambiguity.
This approach can be implemented in a self-serve manner via Slack by deploying our open source Group Profile Manager available in our Labs repository.
In other words, if:
- one of your users (
Charliein the diagram below) belongs to both Group 1 and Group 2, and
- Group 1 and Group 2 each contain a Resource pointing to the same exact IP address,
then there will be an ambiguity for Charlie when connecting to that IP address:
This model therefore implies a precise User <-> Group <-> Resource mapping.
Overlapping CIDR ranges and wildcard DNS entries
Configuring Resources with overlapping CIDR ranges or wildcard DNS entries is not recommended.
If there is ambiguity created by having two or more Resources defined with identical or overlapping CIDR ranges or wildcard DNS entries, there is no guarantee the Twingate Client will route traffic in the expected manner. The best practice here is always to eliminate any ambiguity that may occur.
As an example:
In Remote Network A (RNA), we have a Resource entry for the CIDR range of
10.0.0.0/24 (this encompasses every IP address between
10.0.0.255) and a Resource entry for the wildcard domain name
*.autoco.com (this encompasses every subdomain DNS entry on the
In Remote Network B (RNB), we have Resources with the same CIDR range and wildcard domain name defined.
If a User belongs to a Group that has access to both RNA and RNB, and the User makes a request for an IP address in the
10.0.0.0/24 CIDR range (e.g.
10.0.0.10) or for a hostname matching the wildcard (e.g.
target.autoco.com), the actual target is ambiguous because it matches Resource entries that exist in two different Remote Networks.
Caveat: Assume we have the same Resource definitions in RNA, but more narrowly defined Resource definitions in RNB such as a single IP address
10.0.0.10 or specific hostname like
target.autoco.com. The more specific definitions of
target.autoco.com will always take priority over the more broadly-defined CIDR range and domain name wildcard so traffic will only route over RNB not over RNA. Consequently, there will never be a way to force traffic to
target.autoco.com over RNA while this ambiguity exists.
Last updated 18 hours ago