Cloud adoption continues to grow feverishly as AWS, Azure, and GCP showed YoY revenue growth of 40%, 48%, 45% respectively in Q4 ‘21. In this digital transformation journey, enterprises have found that you can not simply lift and shift your network designs from on-premises to the cloud and it requires a different approach to build scalable, secure and highly available networks in the cloud.
With all the benefits that come with migrating your infrastructure to the cloud, we take for granted some of the simple networking concepts we can do on-premise that becomes very difficult in the cloud. Today we would like to discuss the problem of overlapping IP address space in the cloud networks and how Alkira can help you address it elegantly at scale.
The IP Overlap Problem
Overlapping IP addresses in the cloud is a common issue that can arise due to various causes. Here are some of the common scenarios:
- Your organization acquires another enterprise and their cloud’s IP ranges overlap with your existing cloud networks.
- During onboarding of on-premise networks to connect them to the cloud, you find overlapping subnets between on-premise sites and cloud networks.
- Consolidation of cloud applications in an organization discovers that there are multiple applications from different development teams that use the same address space of 10.0.0.0/16.
Network Address Translation (NAT) can help, at a complex cost
If these problems occur in a data center, networking teams traditionally address them by configuring Network Address Translation (NAT) on the routers in the access layer. What do you do for cloud networks? NAT Gateways in AWS or Azure only provide outbound internet connectivity for the virtual networks and cannot address these use cases. Building a transit network in the cloud and using a third party device to perform NAT is cumbersome and does not scale. Even the newly minted Private NAT Gateway in AWS is complex to configure and manage.
Alkira NAT Policy, built for multi-cloud networking
NAT policy is a part of Alkira’s intent-based policy framework providing granular controls that can be enforced at a global level. It can be used to address various NAT use cases in enterprise networks. When we discuss NAT use cases with Alkira, we really have to think about how the policy is applied relative to the Alkira CXP. The Alkira CXPs or cloud exchange points form a networking fabric in the cloud that you can connect on-premise sites like SD-WAN or standard IPsec sites, and also connect your cloud networks using native constructs. Once these on-prem sites and cloud networks like VPC or VNets are connected to the Alkira CXPs – where overlapping IP spaces are allowed, Alkira’s policies can be applied network wide to them and part of the policy is NAT.
The Alkira NAT policies can apply to a single connector or a group of connectors or sites. A NAT policy concatenates multiple NAT rules matching traffic based on the first match, and the NAT rules within the policy will apply to traffic coming inbound from the CXP’s perspective. NAT in the reverse direction would apply if bi-directional translation is enabled. We have to think about what we’re matching in terms of traffic coming in from the connector you’re applying the policy to, and the NAT rules will match the traffic flows and then apply the proper translation that we’re trying to accomplish. The diagram below illustrates where the NAT policy is applied.
Figure 1: NAT rules apply to inbound traffic flows on a CXP
The table below shows the different types of NAT that are supported on the Alkira platform. So under source address translation, Dynamic IP and Port is basically port address translation or PAT in a traditional sense, but the context is obviously a little bit different here. Static IP in our case is one-to-one NAT or dynamic NAT use cases when you want to translate a whole subnet to another prefix with the same CIDR – i.e. translating an entire /24 network to another /24. The IP address in the last octet will remain the same. For destination address translation use cases, Static IP or Static IP and Port is typically used when you only want to expose a select number of, let’s say, web servers from a network in the cloud and hide that cloud network’s real prefix from other parts of the network. Static port is similar to port forwarding use case traditionally when you need to forward a particular port to a different port.
Figure 2: Network Address Translation methods supported on Alkira
Solving Overlapping IP’s with Alkira NAT Policy
Now we’re going to walk through a real-world use case of how a customer utilized NAT policy to solve overlapping IP’s in the cloud. This customer leverages Alkira to connect all of their on-premises branch locations to applications in a number of VPCs in AWS.The roll out was straightforward as the branch locations connect to their regional Alkira CXPs using BGP over IPsec and the VPC’s are connected to CXPs using Transit Gateways. As they started to migrate their on-premises locations on day N, they found a branch’s subnet overlapping with a particular VPC in AWS. Limitations due to production traffic prevents the customer from creating a new VPC or reconfiguring the branch IP scheme.
The problematic topology is shown in the diagram below where Branch2’s IP address of 10.8.100.0/24 overlaps with the AWS VPC:
Figure 3: Branch2 and VPC1 having overlapping IP subnets
The requirements from the design are as following:
- NAT VPC1’s traffic when it goes to Branch2
- No changes in traffic from VPC1 to Branch1 and the rest of the network
Due to these requirements, VPC1 will remain 10.8.100.0/24 when its workloads talk to Branch1 or any other parts of the network except Branch2. For traffic from VPC1 to Branch2, we’re going to source NAT 10.8.100.0/24 to the 30.30.30.0/24 subnet shown in the diagram. For Branch2, since it can no longer be seen as 10.8.100.0/24 to the rest of the network, all traffic coming from Branch2 is going to be source NATed to 20.20.20.0/24 regardless of destination. Communication between VPC1 and Branch2 is what generated requirement #1 to NAT VPC1, otherwise the return traffic from Branch2’s original prefix (10.8.100.0/24) to VPC1 (also 10.8.100.0/24) would get blackholed.
The NAT policy applied to Branch2 can be configured with a NAT rule shown below where all traffic from the subnet is source NATed to the 20.x subnet. Additionally, we’re going to check the flag “Match and Invalidate Pre-translated Source Prefix”. That means even though Branch2 is connected to Alkira, the CXP is going to invalidate the 10.8.100.0/24 prefix and prevent it from being advertised to the rest of the network.
Figure 4: NAT rule applied to Branch2
For VPC1’s policy, we only want to match traffic coming from VPC1 going to the NATed IP of Branch2. So, if traffic matches the destination of 20.20.20.0/24 which is the NATed subnet of Branch2, then the source IP will be NATed to the 30.30.30.0/24 subnet. The configuration for the NAT rule in the policy is shown in the diagram below. Note that the “Match and Invalidate Pre-translated Source Prefix” option is not checked because on behalf of VPC1, we want the Alkira CXP to advertise both 10.8.100.0/24 and the translated prefix to the rest of the network.
Figure 5: NAT rule applied to VPC1
With two simple NAT rules in corresponding policies, the desired outcomes are achieved where the two overlapping subnets can now communicate with each other and VPC1’s traffic to the rest of the network is unaffected. The same workflow can be applied to overlapping IP’s between cloud networks, or between two on-premise networks.
Summary
In this blog we discussed the common challenge of overlapping IP address space in the cloud and how Alkira’s NAT policy can be leveraged to address various NAT use cases including overlapping IPs. Furthermore, we demonstrated an example of overlapping prefixes between an on-premise location and a cloud network, and how an Alkira customer solved it with NAT policies. We’ve showed both ease of use and scalability with Alkira’s policy framework.
Learn more about how to build cloud and multi-cloud networks with Alkira at https://www.alkira.com/cloud-networking/
Take a tour of Alkira cloud network as-a-service solution at https://www.alkira.com/virtual-tour
Request your own personalized demo at https://www.alkira.com/demo
