Loading...

Azure VMware Solution using a public IP down to the NSX-T Edge; configure SNAT, No-SNAT & DNAT

Azure VMware Solution using a public IP down to the NSX-T Edge; configure SNAT, No-SNAT & DNAT

Azure VMware Solution

How To Series: Configuring NSX-T SNAT, No-SNAT & DNAT rules

 

Overview

Requirements

Lab Environment

NAT Rules

Kusto for NSX-T NAT Rule Logs

 

Overview

Many Azure VMware Solution customers are new to NSX-T and for a use requiring connecting directly to the internet through and Azure Public IP, then understanding how and when to use NAT functionality is a must have skillset.  This This blog uses an example to walk through the configuration of NSX-T NAT rules to enable access from AVS guest VMs to VMs and services on-premises, in Azure and the Internet.

For this lab, ExpressRoute connections to Azure (vWAN) and to on-premises have been provisioned. 

 

Requirements

  • Internet Connectivity has been set to “Connect using Public IP down to the NSX-T Edge” via the Azure Portal.
  • Cloudadmin (or equivalent role) to the Azure VMware Solution NSX-T console.
  • Azure VMware Solution diagnostics enabled and  log analytics workspace to store the logs configured.

FastTrack_Mark_0-1714935522961.png

 

Figure 1: Log Analytics diagnostics for Azure VMware Solution 

 

  • Check that you have set the 'Configure the AVS SDDC to connect using Public IP down to the NSX-T Edge' in the Internet connectivity under the menu item 'Workload networking/Internet connectivity' option.
  • Create (using the +Add button)  4 Public IPs

FastTrack_Mark_3-1714941202399.png

Figure 2: Setting up the NSX-T public IP and four Internet IPs.

 

 

Lab Environment

There are four routes that will be explored in this lab.  Each route requires specific configuration of the NSX-T NAT rules.  Logs generated by the NAT rules are stored in a log analytics workspace. 

  • From AVS guest VM's to the public Internet
  • From AVS guest VM's to Azure native 
  • From AVS guest VM's to the on-premises environment
  • From the public Internet to a specific VM guest server.

This lab does not incorporate NSX-T Firewall settings; the NAT rules are used for routing, not for traffic restrictions or filtering.  Note that AVS workloads are a range of IP addresses in the 192.168.0.0/24 network range, Azure native IP addresses are 10.5.4.0/22, and the on-premise environment is 172.21.86.0/24 and 192.168.87.0/24

 

FastTrack_Mark_2-1714935783732.png

Figure 3: NSX-T Public IP NAT rules lab.

NAT Rules

SNAT rules are used to allow access to the Internet from virtual machines and NVAs running in the Azure VMware Solution.

No-SNAT rules are used to allow access to on-premises and Azure native services from VMs running in the Azure VMware Solution.

DNAT rules are used to allow access from the Internet to VM's running in the Azure VMware Solution.

 

Create a SNAT rule:

Source Network Address Translation (source-nat or SNAT) allows traffic from a private network to go out to the Internet. First let's make sure that the DNS service can reach the default DNS server 1.1.1.1.  When first logging into the NSX-T interface, first log into NSX-T, alarms will be present because the DNS service is unable to reach the upstream DNS servers at 1.1.1.1.

FastTrack_Mark_0-1715055879854.png

Figure 4:  Alarms showing DNS service 1.1.1.1 is unreachable.

 

In this scenario, we want the application servers AppServer-01 and AppServer-02 to be able to access the Internet.

From the NSX-T console select Networking / NAT / Tier-1 Gateway and click on “ADD NAT RULE”

FastTrack_Mark_0-1714938165574.png

Figure 4: Create a SNAT rule

 

Add Name ‘AppServers via HTTP’, select SNAT as the action (default) and enter the two IP addresses of the AppServers (192.168.103.10, 192.168.103.11).  This means the rule only applies to these two IP addresses. Next leave the Destination IP|Port as blank (ie any IP is allowed).  In the translated IP|Port, use the first available public IP (20.95.39.0), or you can fill it in with any of the public IPs created when you configured the portal for NSX-T public IP.  Use a specific IP if you need to enable a partner or customer to add the site/service to a Whitelist.  If you have multiple rules, select a priority to ensure this rule is hit in the correct order.  Note, the lower the number, the higher the priority.  So a rule with priority 10 will be checked before a rule with priority 20.  Enter a description, then click save.

 

FastTrack_Mark_1-1714938333183.png

Figure 5:  Filling the the SNAT rule parameters

 

At this point you will be able to access the Internet from the two AppServers.

Create a No-SNAT rule:

A No-SNAT rule prevents the translation of the internal IP address of packets sent from an AVS SDDC to other networks internal to the organization or otherwise outside of the SDDC environment.  This is important when using the “Connect using Public IP down to the NSX-T Edge” option in the Azure portal because without No-SNAT rules, you will not be able to access Azure or on-premises resources from workloads running in AVS.

In this simple lab environment, the Azure environment contains RFC 1918 addresses 10.X.X.X/8  and the on-premises environment contains 172.21.x.x/16 addresses.   Due to the nature of NAT/SNAT, connectivity from Azure and on-premises network into the 192.168.0.0/22 address exists, however outbound initiated connectivity from AVS workloads  does not.

From the NSX-T console select Networking / NAT / Tier-1 Gateway and click on “ADD NAT RULE”

 

FastTrack_Mark_0-1714940644364.png

Figure 6: Creating a No-SNAT rule

 

This demo configuration is very open, in production you would likely identify specific vNets where you require access, not the entire 10.0.0.0/8 supernet. 

Click on “ADD NAT RULE” and enter the NAT rule Name “Access Azure from AVS”, change the Action to “No-SNAT”.  Set the Source IP to 192.168.96.0/20  (this will cover all of the 192.168.x.x addresses in our lab environment), set the Destination IP|Port to 10.0.0.0/8  and leave the Translated IP|Port empty.   Enter a Description “Enable access from AVS without SNAT. (No-SNAT)”

FastTrack_Mark_2-1714940770649.png Figure 7: No-SNAT rules parameters

 

Create a DNAT rule:

Destination network address translation (DNAT), it is a technique for transparently changing the destination IP address of a routed packet and performing the inverse function for any replies. In this use case, we will create a DNAT rule that enables access to a virtual machine running in the Azure VMware Solution through a public IP address created when you enable the “Connect using Public IP down to the NSX-T Edge” option in the Azure Portal; here you can see we have configured 4 IP public addresses (20.95.39.0 to 20.95.39.3).

 

Create a DNAT rule that allows access on port 80 to the web server running in VLAN-2 with IP address 192.168.101.10.

We are going to assign it a public facing IP address of 20.95.39.1 from the pool of IP’s defined in the screenshot above.

From the NSX-T console select Networking / NAT / Tier-1 Gateway and click on “ADD NAT RULE”

 

FastTrack_Mark_4-1714941385688.png

Figure 8:  Creating a NAT rule to support DNAT.

 

Add in the parameters as described, and enable logging.

FastTrack_Mark_5-1714941479865.png

Figure 9:  Adding the DNAP rule parameters

 

At this point,  go to a web browser and enter http://publicIPselected  and you will see the web site running on your webserver.

 

Tips & Tricks

If access is blocked, check that any NSX-T Distributed firewall rules in place are configured to allow traffic from the Internet to the webserver/service.

 

 

 

Published on:

Learn more
Azure Migration and Modernization Blog articles
Azure Migration and Modernization Blog articles

Azure Migration and Modernization Blog articles

Share post:

Related posts

Azure Fluid Relay: Leveraging Azure Blob Storage to scale Git

Learn how to leverage Git as a storage mechanism behind the globally available Azure Fluid Relay (AFR) service. The post Azure Fluid Relay: Le...

1 hour ago

Verify the integrity of Azure Confidential Ledger transactions with receipts and application claims

In today's digital landscape, the integrity and confidentiality of transactional data are paramount. Microsoft’s Azure Confidential Ledger off...

2 hours ago

HTTP Trigger Azure Function Authorization Types simplified

Here' how you can quickly understand what are the different Authorization Levels to be set while working with HTTP Azure Functions.

1 day ago

Increasing Security for SQL Server Enabled by Azure Arc

Back in November 2023, the least privileges deployment model was introduced as a public preview. After thorough testing, we are excited to ann...

3 days ago

Govern your Azure Firewall configuration with Azure Policies

Introduction:  In the rapidly evolving digital landscape, securing cloud environments is more critical than ever. Azure Firewall emerges ...

3 days ago

Azure Verified Modules - Monthly Update [June]

AVM Module Summary The AVM team are excited that our community have been busy building AVM Modules. As of June 17th, the AVM Footprint curren...

3 days ago
Stay up to date with latest Microsoft Dynamics 365 and Power Platform news!
* Yes, I agree to the privacy policy