Double nat for communication in Azure

This article is a translation of This article is a translation of https://qiita.com/aktsmm/items/c81fb070b09122678d1e

This is Yamapan, a fledgling architect.
I've created an environment to double NAT communication within Azure.

Contents

1 What I want to do this time
2 What to use
3 Configuration we created this time
4 Creating the environment
- 4.1 Vnet-B side
- 4.2 Vnet-A side
  - 4.2.1 1. Copy the alias of the private link service that you just created the environment for.
  - 4.2.2 2. Create a private endpoint on Vnet-A!
5 Trying it out
- 5.1 Check DNAT
- 5.2 Checking SNAT
6 End

What I want to do this time

I want to do double NAT for communication from VM-A to VM-B.

Double NAT: SNAT and DNAT.

Specifically, the image is as follows.

From A's point of view, it is communicating to another IP address, not to B's destination IP.
In addition
From B's point of view, the communication is coming from another IP address, not from A's source IP.
A's source IP address, but another IP address.

If you don't use (double) NAT, you can communicate using the same private IP if you are in the same Vnet, or you can communicate using VNet peering (virtual network peering) if you are in different Vnets.

Virtual Network Peering
https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview

What to use

To achieve this on Azure, use the "Azure Private Link Service" and a load balancer.

:::note info
Use Azure Private Link service for double NAT on Azure
::::

https://learn.microsoft.com/en-us/azure/private-link/private-link-service-overview

Configuration we created this time

First of all, here is a punch picture.
This time, I would like to create an environment like this and use double NAT for communication from VM-A (10.0.0.4) to VM-B (10.2.0.5).

Creating the environment

For your reference, here is a brief and simple procedure. All resources are created specifying the East Japan region.
Please refer to the following when actually creating the environment.
https://learn.microsoft.com/en-us/azure/private-link/private-link-service-overview

Linking the punch picture to the actual resource name

VM-A: VM-Win2019 (10.0.0.4)
VM-B: VM-Win2019-2 (10.0.0.5)
Vnet-A: RG-normal-vnet (10.0.0.0/16)
　Subnet-A:default (10.0.0.0/24)
Vnet-B:temp-vnet (10.2.0.0.0/16)
　Subnet-B:default (10.2.0.0.0/16)
LB: LB-temp
Private link service: PrivateLink-01

Vnet-B side

1. Create LB

Create an internal load balancer.

2. Create VM-B

3. Place VM-B under the LB and configure NAT settings.

This time, we used the following configuration values.

Front-end IP
Backend pool !
Inbound NAT

I set up an inbound rule named RDP on port 3389 for both frontend and backend because I want to do RDP.

4. Create a Private Link Service

Search and create a Private Link Service from Azure Portal.

Configuration values were created in this case as follows.

After creation, NAT IP 10.2.0.6 was assigned.

Vnet-A side

Next, Vnet-A side!

1. Copy the alias of the private link service that you just created the environment for.

(You can also check the NAT IP allocated by Dynamic (Dynamic) here.)

2. Create a private endpoint on Vnet-A!

Follow the wizard to paste the alias you copied earlier during creation.
This time the settings are as follows.

Now your environment creation is complete!

Trying it out

I would like to try RDP from VM-A to VM-B.
Specifically, I would like to RDP from VM-A to a Private EndPoint and connect to VM-B.
Note that Vnet peering between Vnet-A and Vnet-B is not configured this time, so RDP from VM-A to VM-B address 10.2.0.5 will not connect because the Vnet is different.

IP address

VM-A: VM-Win2019 (10.0.0.4)
Private EndPoint (10.0.0.6)
VM-B: VM-Win2019-2 (10.2.0.5)
Private Link Service (10.2.0.6)

Check DNAT

The RDP window from VM-A shows the Private EndPoint as 10.0.0.6, but the actual private IP is 10.2.0.5, indicating that DNAT is in effect.
→ From VM-A, 10.0.0.6 (Private EndPoint's IP) appears to be the address (destination) of VM-B, but in fact it is not.

Checking SNAT

To confirm SNAT, I would like to take a packet capture of VM-B.
Please refer to the following for how to take a packet capture of Azure VM.

https://qiita.com/aktsmm/items/6d77b8af1eb10f28cab5
I took a packet capture of VM-B, and the result of wireshark is as follows.

The only IP addresses that show up are VM-B's own 10.2.0.5 and the NAT IP of the private link service 10.2.0.6, which also shows that SNAT is in effect.
→ From VM-B's point of view, 10.2.0.6 (NAT IP of Private Link Service) appears to be the address (source) of VM-A, but it is not.

End

This time, all the resources were created in East Japan, but it is possible to create resources in different regions.
It is also possible to communicate from on-premises.
The following is an excerpt from the official Docs.

Private Link service can be accessed from approved private endpoints in any public region. The private endpoint can be reached from the same virtual network and regionally peered virtual networks. The private endpoint can be reached from globally peered virtual networks and on premises using private VPN or ExpressRoute connections.
https://learn.microsoft.com/en-US/azure/private-link/private-link-service-overview#details