Solution: NAT in the Public Cloud<\/h2>\n\n\n\n
The solution is the same as in On-Prem\/DC\/Branch environment. Use NAT. But how to set up NAT in Public Cloud (regardless which one, AWS, Azure, GCP, OCI, Alibaba)? Or how to do it across the Public Clouds? The answer is obvious: leverage Aviatrix feature-set.<\/p>\n\n\n\n
As you might know, the Aviatrix Network and Security Multi-Cloud Architecture brings many different benefits. One of them is possibility of doing NAT of course.<\/p>\n\n\n\n
Aviatrix NAT in Action<\/h2>\n\n\n\nLAB Scenario<\/h3>\n\n\n\n![\"Lab](\"https:\/\/cloud-cod.com\/wp-content\/uploads\/2022\/03\/Scenario-1024x482.png\")
<\/a>Lab Scenario: Overlapping CIDRs used across different Regions<\/figcaption><\/figure>\n\n\n\nThe customer has a presence in Azure (let’s say Region#1). Additionally, it uses Region#2 as a DR-Region (in case of an outage in Region#1). The customer has acquired a company, let’s call it “EnvB” that owns some VNETs in Region#3.<\/p>\n\n\n\n
The scenario might be also that Region#1 and Region#2 would be in one Public Cloud (e.g. AWS) and the newly acquired company Region#3 in GCP. It would not change anything when it comes to our discussion because Aviatrix works the same way in each Public Cloud. Remember: Aviatrix is Cloud-Agnostic<\/strong>.<\/p>\n\n\n\nLab Details<\/h3>\n\n\n\n
Let’s focus on the CIDRs and VNETs deployed in the environment:<\/p>\n\n\n\n
- Region#1 (“Primary”:
- Shared Services Spoke VNET (10.40\/16)<\/li>
- Private Spoke VNET (10.50\/16)<\/li><\/ul><\/li>
- Region#2 (“DR”):
- Shared Services DR VNET (10.40\/16)<\/li>
- Private DR Spoke VNET (10.50\/16)<\/li><\/ul><\/li>
- Region#3 (“EnvB”)
- Spoke-1 VNET (10.40\/16)<\/li>
- Spoke-2 VNET (10.151\/16)<\/li>
- Spoke-3 VNET (10.152\/16)<\/li><\/ul><\/li><\/ul>\n\n\n\n
There is a Shared Services VNET in Region#1. The goal is to have the connectivity from “EnvB” (there are three Spoke VNETs there) to Shared Services VNET. But wait\u2026 one of the EnvB Spoke-VNETs (Spoke-1) and Shared Services VNET use the same CIDR of 10.40\/16. We need a NAT.<\/p>\n\n\n\n
The following VMs have been deployed for verification purposes:<\/p>\n\n\n\n
- Shared-VM in Shared Spoke VNET<\/li>
- Shared-DR-VM in Shared DR Spoke VNET<\/li>
- Test-VM in Spoke-1 VNET<\/li><\/ul>\n\n\n\n
Guess what, all of them are assigned the same Private IP of 10.40.16.4.<\/p>\n\n\n\n![\"The](\"https:\/\/cloud-cod.com\/wp-content\/uploads\/2022\/03\/Scenario_woNAT-1024x478.png\")
<\/a>The required connectivity between Spoke-1 VNET and Shared-Services VNET – leverage NAT<\/figcaption><\/figure>\n\n\n\nPart 1 – Solving Overlapping IPs Issue<\/h2>\n\n\n\n
Let’s focus on the connectivity from Spoke-1 VNET to Shared Services VNET. Two things must be done here:<\/p>\n\n\n\n
- SNAT on Spoke-1 VNET side – to hide the real source IP address of Test-Spoke1-VM
- Spoke-1 VNET will use 10.240\/16 prefix for NAT.<\/li>
- Test-Spoke-1 VM will be hidden behind 10.240.16.4.<\/li><\/ul><\/li>
- DNAT on Shared Services VNET
- Shared Services Spoke VNET will use 10.41\/16 prefix for NAT.<\/li>
- Shared-VM will be known to Spoke-1 VNET as 10.41.16.4.<\/li><\/ul><\/li><\/ul>\n\n\n\n
Configuration on Spoke-1 Gateways<\/h3>\n\n\n\n
Aviatrix Spoke Gateways are the components where NAT will be configured.<\/p>\n\n\n\n
We will leverage the “Custom NAT” Aviatrix feature<\/strong>. The configuration is done under the GATEWAY menu. Please select the proper Gateway and choose the “Edit” option.<\/p>\n\n\n\n![\"SNAT](\"https:\/\/cloud-cod.com\/wp-content\/uploads\/2022\/03\/Spoke1_SNAT-1024x161.png\")
<\/a>SNAT configuration on Spoke-1 Gateways<\/figcaption><\/figure>\n\n\n\nWhere:<\/p>\n\n\n\n
1 – Is a real source IP address of our Test-Spoke1-VM<\/p>\n\n\n\n
2 – Is a NATed destination IP address of Shared-VM. It is not a real IP address of the Shared-VM<\/p>\n\n\n\n
3 – Is the connection between Spoke1-Gateways and Transit-EnvB-Gateways<\/p>\n\n\n\n
4 – Is a SNAT IP that will be used as a source of the packet outside of the Spoke1-VNET<\/p>\n\n\n\n
Please notice the same translation must be configured on HA Spoke-1 Gateway.<\/p>\n\n\n\n
Configuration on Shared-Services Spoke Gateways<\/h3>\n\n\n\n
Now, let’s configure Destination NAT on Shared Services Spoke Gateways:<\/p>\n\n\n\n![\"DNAT](\"https:\/\/cloud-cod.com\/wp-content\/uploads\/2022\/03\/Shared_DNAT-1024x177.png\")
<\/a>DNAT configuration on Shared-Services Spole Gateways<\/figcaption><\/figure>\n\n\n\nWhere:<\/p>\n\n\n\n
1 – Is the source IP address of the packet after SNAT<\/p>\n\n\n\n
2 – Is the destination IP address of Shared-VM. It is NOT a real IP address but it is a NAT-IP.<\/p>\n\n\n\n
3 – Is the connection between Shared-Spoke-Gateways and Transit-Gateways<\/p>\n\n\n\n
4 – Is a real IP address of Shared-VM<\/p>\n\n\n\n
Spoke-1 Gateways (Region#3) advertise the NAT CIDR 10.240\/16.<\/p>\n\n\n\n
At the moment the NAT CIDR 10.41\/16 is only advertised by Shared-Services Spoke Gateways in “primary” Region#1.<\/p>\n\n\n\n
Such advertisement is not done by “Shared-Services-DR”.<\/p>\n\n\n\n
All looks good. But there is one gotcha here. Aviatrix Spoke Gateways and Transit Gateways form an ActiveMesh. It is a full mesh of connections between them. This is the reason why we might face an issue with asymmetric routing. The way is required to ensure the symmetry of the initial flow and the response flow. The solution: Source NAT on Shared-Services Gateways. The SNAT is going to look like below:<\/p>\n\n\n\n![\"Additional](\"https:\/\/cloud-cod.com\/wp-content\/uploads\/2022\/03\/Shared_SNAT-1024x157.png\")
<\/a>Additional SNAT required on primary Shared-Services Spoke Gateway for traffic symmetry<\/figcaption><\/figure>\n\n\n\nWhere:<\/p>\n\n\n\n
1 – The real prefix inside Shared Services VNET where the destination Shared-VM resides<\/p>\n\n\n\n
2 – eth0 interface, the interface attached to subnet in Spoke VNET. Let’s call it an “internal” interface.<\/p>\n\n\n\n
3 – None<\/p>\n\n\n\n
4 – The IP address of that (Primary) Shared-Services Gateway eth0 interface<\/p>\n\n\n\n
The SNAT rule is also required on HA-Shared-Services Gateway. The only difference is the “SNAT IPS” address. In this case, it is going to be the IP address of the HA-Shared-Services Gateway eth0 interface:<\/p>\n\n\n\n![\"Additional](\"https:\/\/cloud-cod.com\/wp-content\/uploads\/2022\/03\/Shared_SNAT_HA-1-1024x162.png\")
<\/a>Additional SNAT required on HA Shared-Services Spoke Gateway for traffic symmetry<\/figcaption><\/figure>\n\n\n\nWhat do those 2 SNAT entries (one on Primary Shared-Services Spoke Gateway and the other on HA Shared-Services Spoke Gateway) perform? They ensure that the return traffic will be routed to the Spoke Gateway where the initial traffic landed.<\/p>\n\n\n\n
Testing the connectivity from Spoke1-VM to Shared Services-VM<\/h3>\n\n\n\n
Let’s test whether the connectivity works. We must use NATed 10.41.16.4 IP address as a destination of course. All looks good. The connectivity is there.<\/p>\n\n\n\n![\"PING](\"https:\/\/cloud-cod.com\/wp-content\/uploads\/2022\/03\/Test1-PING_towards_Shared.png\")
<\/a>PING Test for the connectivity between Spoke1-VM and Shared-VM<\/figcaption><\/figure>\n\n\n\nPart 2 – Disaster Recovery Setup<\/h2>\n\n\n\n
As mentioned at the beginning, the customer leverages Region#2 as a Disaster Recovery. What is even more important, it is a “Hot DR”. Why “Hot”? It means the customer has all the VNETs and Aviatrix Gateways already deployed in DR-Region#2. What is more, the Transit Gateways of DR Region#2 peer with Transit Gateways in “primary” Region#1<\/p>\n\n\n\n
Depending on the application, in theory, we could also have the mirror VMs deployed in Region #2, which will be ready to take the load in case Region#1 fails. I have deployed Shared-DR-VM in Shared Services DR Spoke VNET. The IP address of the VNET (10.40\/16) and the DR-VM (10.40.16.4) are the same as in Primary Region #1.<\/p>\n\n\n\n
Additionally, I have created the same DNAT and SNAT rules on “Shared Services DR” Spoke Gateways as the ones present on (Region#1) “Shared Services” Spoke Gateways. There is also one more thing to be considered. We want to have a Disaster Recovery environment in Region#2. In normal conditions, Region#2 must not get any traffic. Though as soon as Region#1 fails, Region#2 must take all the traffic. How to ensure the traffic goes to Region#1 and not Region#2? The answer is simple. Aviatrix Gateways leverage BGP, so we can configure AS Path Prepend in the desired way.<\/p>\n\n\n\n![\"Disaster](\"https:\/\/cloud-cod.com\/wp-content\/uploads\/2022\/03\/Scenario_NAT_details-1-1024x473.png\")
<\/a>Disaster Recovery scenario with Overlapping IP CIDRs<\/figcaption><\/figure>\n\n\n\nAS Path Prepend on Aviatrix Gateways<\/h3>\n\n\n\n
Let’s see how AS Path Prepend could be done on Transit DR Gateways (go to ULTI-CLOUD TRANSIT -> Advanced Config -> choose Transit Gateway). We will put two additional ASN = 65000 when advertising prefixes to BGP peers. Please notice that AS Path Prepend can be done per Connection basis as well.<\/p>\n\n\n\n![\"Configuring](\"https:\/\/cloud-cod.com\/wp-content\/uploads\/2022\/03\/ASPathPrepend-300x177.png\")
<\/a>Configuring AS Path Prepend on Transit Gateway<\/figcaption><\/figure>\n\n\n\nNow we can start advertising the NAT CIDR 10.41\/16 from “Shared-Services-DR” Spoke Gateways.<\/p>\n\n\n\n
Please remember that Aviatrix provides the possibility not only to check the routing table on the Gateway but also all the routing information (“Route Info DB Details”) received by the Gateway. We will verify now how the routing information looks like for prefix 10.41\/16 (the one used by NAT on Shared-Services Spoke Gateways and Shared-Services-DR Spoke Gateways).<\/p>\n\n\n\n
If we look at the “Route Info DB Details” on Transit-EnvB Gateways, we can see that there are two paths: one via Transit Gateways in “primary” Region#1 and the other towards Transit-DR Gateways in Region#2. Region#1-one is chosen as the best route because there is AS Path Prepend done by Transit-DR Gateways as shown below:<\/p>\n\n\n\n![\""Route](\"https:\/\/cloud-cod.com\/wp-content\/uploads\/2022\/03\/RouteDB_TransitGW_normal-1024x199.png\")
<\/a>“Route Info DB Details” on Transit-EnvB Gateway<\/figcaption><\/figure>\n\n\n\nRegion#1 “outage”<\/h3>\n\n\n\n
Let\u2019s see what happens if \u201cShared-Services\u201d VNET in the primary Region#1 is no longer available.<\/p>\n\n\n\n![\"Region#1](\"https:\/\/cloud-cod.com\/wp-content\/uploads\/2022\/03\/Scenario_outage-1024x475.png\")
<\/a>Region#1 outage<\/figcaption><\/figure>\n\n\n\nThe best path towards 10.41.0.0\/16 has been dynamically updated. Keep in mind, the backup route (with AS Path Prepend) was already present in “Route Info DB” before an outage.<\/p>\n\n\n\n![\""Route](\"https:\/\/cloud-cod.com\/wp-content\/uploads\/2022\/03\/RouteDB_Transit_failover-1024x170.png\")
<\/a>“Route Info DB Details” on Transit-EnvB Gateway after Region#1 outage<\/figcaption><\/figure>\n\n\n\n
![\"Lab](\"https:\/\/cloud-cod.com\/wp-content\/uploads\/2022\/03\/Scenario.png\")
<\/a>The customer has a presence in Azure (let’s say Region#1). Additionally, it uses Region#2 as a DR-Region (in case of an outage in Region#1). The customer has acquired a company, let’s call it “EnvB” that owns some VNETs in Region#3.<\/p>\n\n\n\n
The scenario might be also that Region#1 and Region#2 would be in one Public Cloud (e.g. AWS) and the newly acquired company Region#3 in GCP. It would not change anything when it comes to our discussion because Aviatrix works the same way in each Public Cloud. Remember: Aviatrix is Cloud-Agnostic<\/strong>.<\/p>\n\n\n\n Let’s focus on the CIDRs and VNETs deployed in the environment:<\/p>\n\n\n\n There is a Shared Services VNET in Region#1. The goal is to have the connectivity from “EnvB” (there are three Spoke VNETs there) to Shared Services VNET. But wait\u2026 one of the EnvB Spoke-VNETs (Spoke-1) and Shared Services VNET use the same CIDR of 10.40\/16. We need a NAT.<\/p>\n\n\n\n The following VMs have been deployed for verification purposes:<\/p>\n\n\n\n Guess what, all of them are assigned the same Private IP of 10.40.16.4.<\/p>\n\n\n\n Let’s focus on the connectivity from Spoke-1 VNET to Shared Services VNET. Two things must be done here:<\/p>\n\n\n\n Aviatrix Spoke Gateways are the components where NAT will be configured.<\/p>\n\n\n\n We will leverage the “Custom NAT” Aviatrix feature<\/strong>. The configuration is done under the GATEWAY menu. Please select the proper Gateway and choose the “Edit” option.<\/p>\n\n\n\n Where:<\/p>\n\n\n\n 1 – Is a real source IP address of our Test-Spoke1-VM<\/p>\n\n\n\n 2 – Is a NATed destination IP address of Shared-VM. It is not a real IP address of the Shared-VM<\/p>\n\n\n\n 3 – Is the connection between Spoke1-Gateways and Transit-EnvB-Gateways<\/p>\n\n\n\n 4 – Is a SNAT IP that will be used as a source of the packet outside of the Spoke1-VNET<\/p>\n\n\n\n Please notice the same translation must be configured on HA Spoke-1 Gateway.<\/p>\n\n\n\n Now, let’s configure Destination NAT on Shared Services Spoke Gateways:<\/p>\n\n\n\n Where:<\/p>\n\n\n\n 1 – Is the source IP address of the packet after SNAT<\/p>\n\n\n\n 2 – Is the destination IP address of Shared-VM. It is NOT a real IP address but it is a NAT-IP.<\/p>\n\n\n\n 3 – Is the connection between Shared-Spoke-Gateways and Transit-Gateways<\/p>\n\n\n\n 4 – Is a real IP address of Shared-VM<\/p>\n\n\n\n Spoke-1 Gateways (Region#3) advertise the NAT CIDR 10.240\/16.<\/p>\n\n\n\n At the moment the NAT CIDR 10.41\/16 is only advertised by Shared-Services Spoke Gateways in “primary” Region#1.<\/p>\n\n\n\n Such advertisement is not done by “Shared-Services-DR”.<\/p>\n\n\n\n All looks good. But there is one gotcha here. Aviatrix Spoke Gateways and Transit Gateways form an ActiveMesh. It is a full mesh of connections between them. This is the reason why we might face an issue with asymmetric routing. The way is required to ensure the symmetry of the initial flow and the response flow. The solution: Source NAT on Shared-Services Gateways. The SNAT is going to look like below:<\/p>\n\n\n\n Where:<\/p>\n\n\n\n 1 – The real prefix inside Shared Services VNET where the destination Shared-VM resides<\/p>\n\n\n\n 2 – eth0 interface, the interface attached to subnet in Spoke VNET. Let’s call it an “internal” interface.<\/p>\n\n\n\n 3 – None<\/p>\n\n\n\n 4 – The IP address of that (Primary) Shared-Services Gateway eth0 interface<\/p>\n\n\n\n The SNAT rule is also required on HA-Shared-Services Gateway. The only difference is the “SNAT IPS” address. In this case, it is going to be the IP address of the HA-Shared-Services Gateway eth0 interface:<\/p>\n\n\n\n What do those 2 SNAT entries (one on Primary Shared-Services Spoke Gateway and the other on HA Shared-Services Spoke Gateway) perform? They ensure that the return traffic will be routed to the Spoke Gateway where the initial traffic landed.<\/p>\n\n\n\n Let’s test whether the connectivity works. We must use NATed 10.41.16.4 IP address as a destination of course. All looks good. The connectivity is there.<\/p>\n\n\n\n As mentioned at the beginning, the customer leverages Region#2 as a Disaster Recovery. What is even more important, it is a “Hot DR”. Why “Hot”? It means the customer has all the VNETs and Aviatrix Gateways already deployed in DR-Region#2. What is more, the Transit Gateways of DR Region#2 peer with Transit Gateways in “primary” Region#1<\/p>\n\n\n\n Depending on the application, in theory, we could also have the mirror VMs deployed in Region #2, which will be ready to take the load in case Region#1 fails. I have deployed Shared-DR-VM in Shared Services DR Spoke VNET. The IP address of the VNET (10.40\/16) and the DR-VM (10.40.16.4) are the same as in Primary Region #1.<\/p>\n\n\n\n Additionally, I have created the same DNAT and SNAT rules on “Shared Services DR” Spoke Gateways as the ones present on (Region#1) “Shared Services” Spoke Gateways. There is also one more thing to be considered. We want to have a Disaster Recovery environment in Region#2. In normal conditions, Region#2 must not get any traffic. Though as soon as Region#1 fails, Region#2 must take all the traffic. How to ensure the traffic goes to Region#1 and not Region#2? The answer is simple. Aviatrix Gateways leverage BGP, so we can configure AS Path Prepend in the desired way.<\/p>\n\n\n\n Let’s see how AS Path Prepend could be done on Transit DR Gateways (go to ULTI-CLOUD TRANSIT -> Advanced Config -> choose Transit Gateway). We will put two additional ASN = 65000 when advertising prefixes to BGP peers. Please notice that AS Path Prepend can be done per Connection basis as well.<\/p>\n\n\n\n Now we can start advertising the NAT CIDR 10.41\/16 from “Shared-Services-DR” Spoke Gateways.<\/p>\n\n\n\n Please remember that Aviatrix provides the possibility not only to check the routing table on the Gateway but also all the routing information (“Route Info DB Details”) received by the Gateway. We will verify now how the routing information looks like for prefix 10.41\/16 (the one used by NAT on Shared-Services Spoke Gateways and Shared-Services-DR Spoke Gateways).<\/p>\n\n\n\n If we look at the “Route Info DB Details” on Transit-EnvB Gateways, we can see that there are two paths: one via Transit Gateways in “primary” Region#1 and the other towards Transit-DR Gateways in Region#2. Region#1-one is chosen as the best route because there is AS Path Prepend done by Transit-DR Gateways as shown below:<\/p>\n\n\n\n Let\u2019s see what happens if \u201cShared-Services\u201d VNET in the primary Region#1 is no longer available.<\/p>\n\n\n\n The best path towards 10.41.0.0\/16 has been dynamically updated. Keep in mind, the backup route (with AS Path Prepend) was already present in “Route Info DB” before an outage.<\/p>\n\n\n\nLab Details<\/h3>\n\n\n\n
<\/a>Part 1 – Solving Overlapping IPs Issue<\/h2>\n\n\n\n
Configuration on Spoke-1 Gateways<\/h3>\n\n\n\n
<\/a>Configuration on Shared-Services Spoke Gateways<\/h3>\n\n\n\n
<\/a><\/a><\/a>Testing the connectivity from Spoke1-VM to Shared Services-VM<\/h3>\n\n\n\n
<\/a>Part 2 – Disaster Recovery Setup<\/h2>\n\n\n\n
<\/a>AS Path Prepend on Aviatrix Gateways<\/h3>\n\n\n\n
<\/a><\/a>Region#1 “outage”<\/h3>\n\n\n\n
<\/a><\/a>