Mind the Overlap

Dealing with Clashing CIDRs

Note — I am not by trade a “networking guy”. However, I’ve seen my fair share of network designs. Take this with a grain of salt, but also ignore this at your own risk.

Sometimes, despite all efforts otherwise, it’s not possible to create perfectly segmented, non-overlapping networks (like if you have a need for 18M private IP addresses[1]). Other times, it is deemed convenient to reuse ranges (one thing that I’ve encountered more than once is the notion of reusing ones production network ranges as the dev/int/test/etc. environment ranges[2]). There’s even the strong possibility that there isn’t a single, centralized team making decisions regarding IP allocation. Rather than focusing on “Why it happened?”, we want to understand “How to proceed?”.

How do network architects approach integrating two private networks with overlapping CIDRs?

Network Segmentation

Before we go into how to integrate two private networks that have clashing IPs, we should first mention that, ideally, one should probably avoid needing to integrate such private networks in the first place. If you’d like some guidance on how to develop a network architecture that avoids such circumstances, check out the previous post here.

Reusing Ranges

There are several options available and a reasonable architecture for a massive organization may include more than one. One clear and very common component to consider is to use network address translation (NAT; this is also sometimes how we refer to the device that performs this process, or “NAT gateway”, or “NAT appliance”, etc.). NATs are great for one way communication (or, perhaps more accurately, one way initiated communication): when you have a clear downstream/upstream relationship between components. The upstream contacts the downstream through the NAT gateway, and the upstream service’s IP address is translated to the NAT’s own IP address, for use by components on the downstream network. Return traffic is sent back to the NAT, which will translate the destination back to the original upstream address. The catch is that the originating component cannot use the IP address of the downstream component: they must instead leverage the component by host or domain name. An internal DNS solution helps to bridge the gap between two NAT-linked networks.

If mission critical traffic is expected to be over the public Internet, it is almost certainly necessary to encrypt it. This is where a virtual private network (VPN) becomes an attractive option. For our purposes, a VPN works much like a NAT. DNS would again be included to direct traffic through the VPN. In fact, DNS is a big part of any solution that connects two networks that have common IP addresses to avoid any confusion when attempting to communicate between them. DNS is the real hero of the story[3].

When two-way communication is needed, it is possible to simply use two NATs or VPNs[4] (and corresponding DNS), one for each network. Generally, I would say most solutions will include either NAT or VPN, or a variant of one of them, and DNS. Even hub-and-spoke or similar solutions that use “network peering” will typically need to include them (and many platforms/providers impose unique ranges across networks that are indirectly connected[5]).

Two NICs Are Better Than One

However, this does all presuppose the traffic between two networks is the same kind of traffic that the networks themselves were designed to support. Or another way to say it: it assumes the traffic needs to go over the same network interface controller (NIC). This is not always the case.

Depending on the nature of the traffic with which the two entities on each overlapping network need to communicate A) for their respective primary function, and B) with each other, it may be most prudent to simply use a third network[6], connected to each entity over a second NIC. If, for example, one entity is an application webserver for our corporate website, and the other is a logging sink for access logs (which itself has a frontend user interface, for site reliability engineers to access), then there’s no reason for them to communicate over the same network interface that serves traffic up the chain to end-users’ web browsers. In fact, that very example is likely to impose unwanted throughput constraints that grow proportionally with usage. This is an example of “east-west” traffic, and there is little drawback in architecting one’s network this way (beyond the cost of implementing and the headache the architecture diagrams can induce on those that behold them). However, there are still rules and best practices in introducing these “second NIC networks” (a perhaps obvious one being to not try to use the same IP for both NICs of the same machine), and some care must still be taken.

So far, I’ve only discussed IPv4, but another approach would be to use IPv6, instead. However, I mention it purely to be as holistic as possible. To be honest, I have never personally touched IPv6, and would defer any novel guidance to anyone else. I would say that this should be functionally equivalent to the “second NIC” approach above. I would also suggest that the continued lack of adoption for IPv6, despite it being considered a “standard” since 2017, may relegate it to very specific cases and thought experiments, until we begin to reach critical mass in the public Internet that we can’t find ways to work around.

Public Internet Route

A last, perhaps least gratifying, approach I’ll mention is simply exposing one or both networks to the public Internet and communicating as if the two sides were each third-party integrations. While this seems like a lazy approach, I think this is actually more common than we would like to admit. That being said, I don’t think it’s so especially pervasive or commonly systemic as to be a problem; I think it happens here and there and any impact is relatively negligible in many cases. This might be a “reasonable solution” in cases where:

• You already have a robust, secure, and accessible/extendable system for ingress and egress over the public Internet,

• You do not yet have a convenient pattern with which to establish communication between two given, overlapping networks,

• The phenomenon is determined to be “one-off” or to have an extremely low likelihood of recurrence, and

• The traffic is neither sensitive in nature or in timeliness.

Conclusion

As you can see, there are a few options to consider if it is necessary to integrate networks with colliding CIDRs. The most common components, DNS, NATs, and VPNs, most likely are already included at various points in one’s architecture, so the patterns should already be familiar and available. Other options like secondary NICs can provide performance benefits beyond simply enabling connectivity. When all else fails, there is even the good old public Internet. This commentary is by no means intended to be exhaustive, but merely illustrative of common approaches.

Check out cidrclash.com today and don’t let clashing networks ruin your day!

---

Footnotes:

[1] Super common wink wink.

[2] I don’t know that this is inherently an anti-pattern, but it seems to coincide with hard coded addresses somewhere in the stack, which is never ok.

[3] Border Gateway Protocol (BGP) can also be used internally in conjunction with DNS for very large, complex networks. I will defer guidance on when and how to implement this.

[4] FWIU some VPNs can provide full two-way communication over the same physical link (where the upstream and downstream can compete for the total throughput of the link), but this is more of an internal implementation detail that is beyond both this discussion and my knowledge.

[5] DNS often provides a greater role in these solutions, in general, as most platforms/providers do not support transitive routing across network peers.

[6] Or collection of networks.

This article was originally published on Medium on 01/13/2025