How Overlapping IPs Cause Problems for Your Business (and How to Fix It)

When businesses set up local networks, they often aren’t thinking about the long term implications of the address spaces they use. This applies to office networks, edge sites, data center VLANs, cloud VPCs, and Kubernetes clusters.

It is very common to reuse the same local address spaces (e.x: 192.168.1.0/24) for multiple sites. After all, those addresses only get used locally, so what’s the problem?

The issue occurs down the road, when businesses want to provide remote access to these systems, or provide site-to-site connectivity between them (e.x:, treat multiple offices as one big local network). This is because if you’d like to provide connectivity to, or between, multiple sites that reuse the same address space, traffic may not know where to go. 

For example, consider an administrator setting up access to multiple offices, but they all use the same local network space (192.168.1.0/24). They can provide a remote access VPN to users, but their workstations won't know exactly where to go to reach network endpoints at office A vs office B since locally, they are identical. Devices on both sites are pulling addresses from the same pool, so, for instance, you may have a server at both offices using the exact same address like 192.168.1.25.

In such scenarios, it becomes ideal to utilize network address translation. Essentially, we want to pretend as if a site is using a different address space than it is. Let’s say you have three sites, all using 192.168.1.0/24. In such a scenario, you want your remote users to be able to reach all three sites, but the addresses will conflict. So instead, you assign a different virtual address space to each site, which maps to the correct local address. So for instance, you may set up a virtual NAT for each site as follows:

Site 1: 10.10.1.0/24 → 192.168.1.0/24

Site 2: 10.10.2.0/24 → 192.168.1.0/24

Site 3: 10.10.3.0/24 → 192.168.1.0/24

If you can achieve this, then, if you have a server sitting at Site 2 on 192.168.1.48, a user would simply need to use 10.10.2.48 in order to reach the server, and it will be mapped appropriately. This can also be used with site-to-site networks, so that you can treat all three sites as one local network, and devices on Site 1 can reach devices on Site 3 without conflict.

Setting up such a system requires considerable skill and time, which is why Netmaker has developed a system to deploy virtual NAT’ing on multiple sites with hardly any administrative work. 

In short, with Netmaker, it works as follows:

1. Deploy a Netmaker agent at each site
2. Create Egress routes for each site, which tells the agent to forward traffic locally
   
   1. Input the local site address space, e.g. 192.168.1.0/24
   2. Select Virtual NAT from the NAT options
3. Upon creation, netmaker will assign a unique virtual address space from an available pool, e.g. 10.27.58.0/24
4. Users and devices can now use this alternative address space to access the site.

This system solves a variety of problems in remote access and site-to-site networking scenarios where conflicting IP spaces get in the way. From Kubernetes, to the data center, to offices, to edge locations, you’ll find that conflicting address spaces pop up more frequently than you might expect. In such scenarios, you might want to give Netmaker a try, and see how we can help resolve these issues.

Ready to learn more? Reach out to our team for a demo, and we’d be happy to show you how it works.

‍