Organizations often encounter difficulties when IP ranges (or CIDR) overlap within their network. This could occur for several reasons:
- Mergers and Acquisitions – each company’s network planning is done independently and has a high probability of overlapping CIDR
- Cloud-based Service Offerings – often, the nature of SaaS businesses is to provide services to customers in their accounts. This typically involves connections between a central service hub and the customer’s accounts.
- Consolidation – Organizations are trying to consolidate security infrastructure for the ease of management and cost reduction.
- Insufficient Planning – Projects might start as proof of concept and should have reworked the network to avoid overlapping CIDR, but they never got around to doing it.
In any case, you have the same problem: How can you create granular policies to distinguish between different VPCs with overlapping CIDRs?
Overlapping CIDR = Ineffective Networking and Security
It is hard to create policies that match one VPC and not the others when you have overlapping CIDR in the network. Policy matching is typically done based on IP address, and since the VPCs have overlapping CIDRs, there are chances that the traffic from 2 different VPCs has the same IP. As a result, you’ll come across issues like:
- Cannot create granular policy based on the intended VPC.
- Because of overlapping CIDR, traffic is affected when the intention is to block a different VPC.
- Traffic is allowed when it is supposed to be blocked.
- Need extra logic to assign a new IP range for services provided to customers.
Most security vendors today only support IP-based policy definitions, meaning the matching address object must be IP or CIDR. A typical scenario shown in the diagram below is if we use an existing solution to create IP-based policies, the security vendor will not be able to distinguish between VPC A from VPC B or VPC C because they all share the same CIDR. As a result, customers will need to renumber the network to eliminate overlapping CIDR, which is time-consuming and sometimes impossible due to the design.
There are other ways to normalize the network to address network connectivity (as mentioned by the AWS blog: Connecting Networks with Overlapping IP Ranges). Still, most of them require a massive effort to migrate to an eventual state which does not have overlapping IP ranges. Furthermore, this network overhaul addresses the connectivity portion, not the security portion.
How can one overcome the challenge without the complex network overhaul or complex logic to ensure the uniqueness of CIDRs? Valtix can help here.
Valtix Can Help With Cloud-Native Networking
Valtix addresses the overlapping CIDR issue by integrating the Gateway Load Balancer (GWLB) with our solution inside the Valtix Gateway. Valtix Gateway is an autoscaling entity that consists of GWLB. The introduction of AWS Gateway Load Balancer(GWLB) allows Valtix to extract the GENEVE header information as an additional parameter to distinguish traffic originating from each VPC. Therefore, if we look at the same scenario above, Valtix can provide security based on the intended VPC, as shown below.
Other legacy security vendors might also use GWLB in their solution, but their goal is to intercept the session to perform policy matching based on the legacy method – IP-based policy matching. IP-based policy matching works well in a static environment (on-prem datacenters) where changing addresses or adding a new network space is rare. However, in a dynamic environment (public cloud), the creation of new VPCs or network change will happen more frequently than in on-prem datacenters, and hence you want to define your policy based on the VPC, and not the IP or CIDR. This is how we have seen our customers in the cloud define it in a dynamic environment.
As other cloud providers provide overlay capabilities like the AWS GWLB, Valtix will integrate with the cloud platform and offer the same ability we provide in AWS.
How to Configure Valtix to Address Overlapping CIDR in 5 Steps
Below, we’ll run through the five (5) steps to configuring Valtix to implement effective security and networking despite overlapping CIDR.
Step 1: Onboard AWS Account to Valtix Controller
Step 2: Deploy Valtix Gateway
Step 3: Deploy endpoint in spoke VPC
Step 4: Create an Address Object to match VPC
Step 5: Apply the Address Object in the policy
Valtix enables effective security and networking in any cloud environment. Even with conflicting addresses or multiple clouds, Valtix can deploy quickly and easily. Your teams can now create policies that work on the intended workloads, regardless of app or infrastructure architecture. Try Valtix with our Free-Tier sign-up.