Azure VMware Solution – Use public IP on NSX-T Edge

A few days ago, Microsoft released a new feature for Azure VMware Solution: Enable Public IP to the NSX Edge. I take the opportunity to review this new feature and the other options available to provide Internet connectivity to your Azure VMware Solution (both for In or Out-bound traffic).

Internet access options for Azure VMware solution

To provide internet access (inbound and/outbound) to an Azure VMware Solution deployment, 3 options are available:

1. Use a Microsoft-managed SNAT (outbound connectivity only) (doc.)
2. Advertise a default route using Azure Firewall, Azure vWAN or a third-party Network Virtual Appliance (NVA) (doc.)
3. Use Public IP address(es) published down to the NSX-T Edge (doc.)

Each option has its own advantages and disadvantages and is summarized below.

Microsoft-managed SNAT

The Microsoft-managed SNAT option (doc.) is the easiest and cost-effective option for outbound (only) connectivity as the public IP addresses are fully managed by Microsoft free of charge.

In this scenario, 2 public IPs are used and rotated to provide outbound connectivity to the Azure VMware Solution workloads with up to 128 000 concurrent connections.

This comes with the following limitations:

• No inbound connectivity
• No control of outbound SNAT rules
• No connection logs
• Hard limit of 128 000 concurrent connections

Advertise a default route

The second option for Internet connectivity in Azure VMware Solution is based on the default route advertisement from another component in the Azure infrastructure (doc.).

This advertisement can be done using:

• Azure Firewall
• Azure vWAN
• Third-party Network Virtual Appliance (NVA)
• A routing component deployed on-premises

If no default-route is advertised to AVS, the VMs will not be able to access the internet: this option is also the one used to disable internet access on AVS deployment.

This option could provide inbound connectivity, control of SNAT and DNAT rules, connections logs but is more complex to deploy and will involve additional charges (for public IP addresses, Firewall or routing devices etc.)

Public IP address published down to the NSX-T Edge

What was recently announced as a new GA feature in Azure VMware Solution is the publication of public IP address(es) down to the NSX-T Edge (doc.). This is the third option for Internet connectivity in Azure VMware Solution and it provides the best of the 2 previous options.

• Inbound and outbound connectivity
• Control of SNAT and DNAT rules
• Connection logs
• No additional components to deploy (Azure Firewall, Azure vWAN, third-party NVA)

On top of this, this new feature also enables:

• A unified experience based on AVS native components only: Azure Resource Manager and NSX-T
• The ability to receive up to 64 public IPs (soft limit)
  • This quota can be increased by request to 1000s of Public IPs allocated if required
• DDoS Security protection against network traffic in and out of the Internet.
• HCX Migration support over the Public Internet.

Pricing considerations

With this new feature, Public IP addresses published for an AVS instance are billed separately from the AVS instance itself as IP addresses used for other Azure purposes.

The pricing details are explained here: IP Addresses pricing and to summarize it:

Reserve public IP addresses for Azure VMware Solution

Since the publication of the new feature providing public IPs on NSX-T Edge, a new section Internet Connectivity is available in the Azure portal to manage AVS internet access options.

To enable internet access with public IPs on NSX-T Edge, at least one public IP block is needed. You can create one by providing a name and the number of IPs you want to allocate.

When the block request is submitted, you can save the new internet access settings. The block will be created and the IPs will be allocated in the background while the block is advertised to the AVS deployment.

It may take around 10 to 15 minutes to complete the new configuration. If internet access was already enable on the AVS deployment, a downtime is expected during the re-configuration and NSX-T configuration will be required.

When the configuration is completed, the new block will be available in the list of public IP blocks:

Enable outbound internet access using SNAT

Enabling outbound internet access requires to configure (at least) a SNAT rule on the NSX-T T1 router.

1. Logging to NSX-T manager
2. In the networking tab, access to the NAT section
3. Select the appropriate T1 router to provision the SNAT rule on
4. Create a new SNAT rule with name, and an IP address from the provisioned block to use for outbound connectivity
5. Save

Enable inbound internet access

Inbound connectivity with DNAT

The inbound internet access could rely on a DNAT rule, forwarding the traffic from the public IP address to the internal IP address of the workload (either a VM or a network service).

1. Logging to NSX-T manager
2. In the networking tab, access to the NAT section
3. Select the appropriate T1 router to provision the DNAT rule on
4. Provide a name, a public IP address from the provisioned block and an internal IP address to forward the traffic to
5. Save

Inbound connectivity with DNAT and port redirection

With the DNAT rule, you can also redirect traffic to a different port. For example, you can redirect traffic from the public IP address on port 80 to a different port on the internal workload, like 8000.

For this, you need to specify a service matching the port of the internal workload during the DNAT rule creation (8000 in our example).

Then to specified as the Translated Port, the port exposed on the public IP address (80 in our example).

Inbound connectivity using NSX-T Load Balancer

As public IP address can now land directly on the NSX-T edge, it is possible to setup a NSX-T Load Balancer to provide inbound connectivity to the AVS workloads.

First step is to create a Load Balancer service, attached to the NSX-T T1 gateway and to specify a sizing.

Second step is to create a Virtual Server, attached to the Load Balancer service and to specify the port and the IP address of the workload.

Then Server Pool is created and attached to the virtual server. It contains a list of workers hosting the load-balancer application.

Last but not least: an Active Monitor is created to monitor the Server Pool.

Conclusion

With the new Public IP address down to the NSX-T edge feature now available for AVS, new capabilities are available to manage the internet connectivity of the AVS workloads. One of the most important advantages is the ability to rely on NSX-T components to configure and securise both inbound and outbound internet connectivity. It is also possible to directly use public IP addresses with NSX-T services like Load Balancer or VPN.

Of course, this setup will not satisfy all the thinkable internet connectivity requirements but it offers a new set of possibilities and is a real asset to consider to host internet-facing applications or to control outgoing internet connections.

Credits

Photo by Clément Duguerre on Unsplash