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 10.1.2.3
.
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 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
fromsubnet1
→server.dev.autoco.com
10.1.2.4
fromsubnet1
→db.dev.autoco.com
10.1.2.3
fromsubnet2
→server.prod.autoco.com
10.1.2.4
fromsubnet2
→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 thedevelopment subnet
server.prod.autoco.com
→10.1.2.3
in theproduction subnet
We would then reconfigure Twingate Resources away from IP address-style Resources and simply use the new FQDNs.
Goodbye, ambiguity
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 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:
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 (
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.
Last updated 2 months ago