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 10.1.2.3.

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.

Let’s resolve this by diving deeper into the three typical options at our disposal. None of these options involves restructuring networks or changing IP addresses, which we know can require significant effort.

Option 1: Use Resource aliases

The first (and in our opinion, best) option is to use Resource aliases to disambiguate the Resources that map to overlapping IP addresses. Each Twingate Resource is mapped to a Remote Network therefore a Resource alias ensures proper routing even if the underlying IP address of the asset is identical to another one from a different Remote Network.

Example:

We can add Resource aliases to the following assets:

• 10.1.2.3 from subnet1 → server.dev.autoco.com
• 10.1.2.4 from subnet1 → db.dev.autoco.com
• 10.1.2.3 from subnet2 → server.prod.autoco.com
• 10.1.2.4 from subnet2 → db.prod.autoco.com

Option 2: Use a private DNS server

The second 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:

Example:

We can create 2 DNS zones, one for each subnet:

• *.dev.autoco.com will be used for all assets in the development environment
• *.prod.autoco.com will 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:

• server.dev.autoco.com → 10.1.2.3 in the development subnet
• server.prod.autoco.com → 10.1.2.3 in the production subnet

We would then reconfigure Twingate Resources away from IP address-style Resources and simply use the new FQDNs.

Option 3: 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:

In other words, if:

• one of your users (Charlie in 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.0 and 10.0.0.255) and a Resource entry for the wildcard domain name *.autoco.com (this encompasses every subdomain DNS entry on the autoco.com domain).

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 10.0.0.10 and 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 10.0.0.10 or target.autoco.com over RNA while this ambiguity exists.