Start For Free
Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors

How to implement a virtual cloud network with Aviatrix & VMware

 

Video demo showcasing a scenario where cloud services that rely on an on-premise billing database can be connected and secured using the Virtual Cloud Network concepts proposed below.</figcaption

 

  1. Introduction
  2. Solution Components
  3. Installing the Aviatrix Cloud Network solution
  4. Configuring your NSX Edge Gateway to interface with the Aviatrix Gateway
  5. Real-world Considerations for Hyper-distributed Applications

Introduction

Aviatrix is a cloud network platform which enables Enterprises to adopt, build and scale their Public Cloud environment. Aviatrix provides a point-and-click, secure networking, designed for cloud engineers to run hybrid and multi-cloud environments. Aviatrix reduces the complexity of traditional networking technologies so that companies can create and deploy the applications they need to achieve their business outcomes—without worrying about how to move workloads between clouds.

VMware NSX Data Center is the network virtualization platform for the Software-Defined Data Center (SDDC), delivering networking and security entirely in software, abstracted from the underlying physical infrastructure.

The Virtual Cloud Network, introduced by VMware, is the category for enterprises designed to handle the varying demands across data centers, clouds, branches and the edge. It is an evolution of the network being adopted across IT to provide the network fabric in support of the increasingly distributed world of apps and data.

Together, NSX Data Center and Aviatrix software defined cloud routers, create a hybrid cloud model for networking and security by allowing IT admins to embrace multiple private and public cloud environments while having one cohesive strategy for network functions and consistent security.

 

This guide details the steps to implement Virtual Cloud Network across Software Defined Data Center(SDDC) and AWS using NSX Data Center and Aviatrix. It also details considerations for managing consistent security policies for applications regardless of their location.

Solution Components

The Aviatrix solution consists of two components: Aviatrix Gateways, which are deployed in the AWS VPCs, and the Aviatrix Controller, a centralized management console which orchestrates and manages one or more Gateways.

NSX in a VMware vCenter environment comprises of NSX Manager, NSX Controller, Distributed Logical Router and an NSX Edge.

2.1 Lab Setup

A lab environment was set up to demonstrate interoperability between NSX datacenter and Aviatrix Cloud networking components. The datacenter environment was built on ESXi running NSX version 6.4. NSX Manager and controllers were installed and configured using the vCenter Server.

A DLR was created on the ESXi cluster and configured with three interfaces, one for each subnet behind it: Web, App and DB. Windows VMs were created in each of these subnets. The VM in the DB subnet also had SQL Server installed on it. The NSX firewall policies allowed VMs in the Web and App subnets to acess the Database VM over TCP ports. The AWS VPC’s IP range was also allowed to access the database in the firewall rules. There is more discussion on security policy and how to implement isolation by default in the Real World Considerations section of this document.

An NSX Edge Gateway VM was created in a fourth subnet (DMZ) with one interface attached to the edge router and one interface attached to Transit Logical Switch that connects to the DLR.

In the Lab’s Amazon Web Services account, an Aviatrix controller was installed in a management VPC. This controller was used to provision Aviatrix Cloud Gateways in the same VPC as the cloud instances that require connectivity to on premise subnets (Web, App and DB).

Installing the Aviatrix Cloud Network solution

The first step in setting up the connectivity between NSX to Aviatrix is to install Aviatrix in the public cloud. In our case, we will use the Aviatrix offering available natively in the AWS marketplace. Aviatrix also offers the Aviatrix Hosted Service which could be used as well.

    1. Install the Aviatrix Controller in an AWS VPC (management VPC preferred)
      To install the Aviatrix Controller in your AWS VPC, follow these steps: http://docs.aviatrix.com/StartUpGuides/aviatrix-cloud-controller-startup-guide.html

Create an Aviatrix Gateway in the VPC you want to connect to the NSX Datacenter.

    1. Log into the controller you deployed in the previous step.
    2. Click on the Gateway Link on the navigation pane
    3. Click on + New Gateway.

    1. Give the gateway a name (no whitespaces or special characters) and pick the appropriate AWS Account, Region, VPC and Subnet where you want to create the Gateway.
    2. Click OK.
    3. The controller will orchestrate instantiation of the Gateway (EC2 instance) in the VPC.
    4. Now that an Aviatrix Gateway has been installed in the AWS VPC, let’s set up the gateway to create an IPSec Tunnel (using the NSX Edge as the Peer Gateway).

    1. Go to the Site2Cloud page in the Aviatrix Controller UI.
    2. Click on “+ Add New” button.

    1. Enter information as shown in the screenshotNote: Remote Subnet needs to match the NSX Subnets and the SDDC Local Subnet needs to match the Cloud VPC CIDRs.

    1. Download the IPSec remote peer configuration template from the Aviatrix Controller.
    2. Instructions for downloading the IPsec Config. template are here.

Configuring your NSX Edge Gateway to interface with the Aviatrix Gateway

4.1 Create an NSX Edge Services Gateway

      1. Log in to the vSphere Web Client and click Networking and Security -> Select NSX Edges (under the Networking and Security section)

      1. Click the green + icon to add a new NSX Edge.

      1. In the Name and description dialog box:
        1. Select Edge Services Gateway as the Install Type.
        2. Enter a name for the NSX Edge services gateway in the Name text box. The name should be unique across all NSX Edge services gateways within a tenant.
        3. (Optional) Enter a host name for the NSX Edge services gateway in the Hostname text box.
        4. (Optional) Enter a description in the Description text box.
        5. (Optional) Enter tenant details in the Tenant text box.
        6. Confirm that Deploy NSX Edge is selected (default).
        7. (Optional) Select Enable High Availability to enable and configure high availability.
        8. Click Next.

      1. In the Settings dialog box:
        1. Leave the default user name of admin in the User Name text box.
        2. Enter a password in the Password and Confirm Password text boxes. The password must be 12 to 255 characters and must contain the following:
          • At least one upper case letter
          • At least one lower case letter
          • At least one number
          • At least one special character
        3. Select the Enable SSH access check box.
        4. Select the Enable auto rule generation check box.
        5. Select EMERGENCY from the Edge Control Level Logging drop-down menu.
        6. Click Next.


      1. In the Configure deployment dialog box:
        1. Select the data center from the Datacenter drop-down menu.
        2. Select the appropriate Appliance Size.
        3. Click the green + icon in the NSX Edge Appliances section.
        4. Select the cluster or resource pool from the Cluster/Resource Pool drop-down menu.
        5. Select the datastore from the Datastore drop-down menu.
        6. (Optional) Select the host from the Host drop-down menu.
        7. (Optional) Select the folder from the Folder drop-down menu.
        8. Click OK and click Next.


      1. In the Configure Interfaces dialog box:
        1. Under the Configure interfaces of this NSX Edge section, click the green + icon to create an interface. Note: You must add at least one internal interface for HA to work.
        2. Enter the NSX Edge interface name in the Name text box.
        3. Select Internal or Uplink as the Type.
        4. Click Change next to the Connected To selection box to choose the appropriate logical switch, standard port group, or distributed port group with which to connect the interface.
        5. Select Connected for the Connectivity Status.
        6. Assign a primary IP address and subnet prefix length.
        7. Select the appropriate options.
        8. Select Enable Proxy ARP for overlapping network forwarding between different interfaces. Select Send ICMP Redirect to convey routing information to hosts.
        9. Click OK and click Next.

      1. In the Default gateway settings dialog box, deselect the Configure Default Gateway check box and click Next.

      1. In the Firewall and HA dialog box:
        1. Select the Configure Firewall default policy check box.
        2. Select Accept for Default Traffic Policy.
        3. Select Disable for Logging.
        4. (Optional) If high availability is enabled, complete the Configure HA parameters section. By default, HA automatically chooses an internal interface and automatically assigns link-local IP addresses.
        5. Click Next.

      1. In the Ready to complete dialog box, review the configuration and click Finish.

Note: NSX Edge supports two virtual machines for high availability, both of which are kept up to date with user configurations. If a heartbeat failure occurs on the primary virtual machine, the secondary virtual machine state changes to active. Thus, one NSX Edge virtual machine is always active on the network. NSX Edge replicates the configuration of the primary appliance on the standby appliance and ensures that the two HA NSX Edge virtual machines are not on the same VMware ESXi® host, even after a vSphere vMotion or vSphere DRS migration.

Note: If ANY is selected for the high availability interface but there are no internal interfaces configured, the user interface will not display an error. Two NSX Edge appliances will be created, but because there is no internal interface configured, the new NSX Edge appliances remain in standby and high availability is disabled. After an internal interface is configured, high availability will be enabled on the NSX Edge appliances.

4.2 Connecting the NSX Edge to Aviatrix Gateway in AWS

      1. Add a NIC Interface card with the public IP of your Edge router.

      1. Get the text file with information obtained from the Aviatrix Controller (downloaded text file from Section 3.)

      1. Navigate to VPN tab of NSX Edge device.,

      1. Fill out the from with the details from the Aviatrix-generated text file (example below). The Yellow shaded regions are the subnets of the NSX Edge VPN Local subnets which should match the Aviatrix subnets.

      1. Publish and Enable the Configurations.,

      1. Check the VPN Connectivity at both Aviatrix and NSX Gateway End.
      2. Ensure you have configured the Global configuration status with a password, Enable the Log level policy and start the IPSec VPN Service.
      3. Also Check the Aviatrix Controller UI in the Site2Cloud Page. You should see the tunnel as up:

      1. Now navigate to your App server/Web Server or DB Server and check the connectivity to the AWS Cloud Instance.

Connectivity Test:

Ping the from datacenter VM (residing within one of the local subnets) to the VPC Instance’s private IP address (198.22.64.230).

Similarly, you can also ping the on-premise environment from the cloud instance.

From the local subnet, packets should reach the NSX Edge gateway, get encrypted, cross the Edge Uplink network, then reach the Edge Router and then the Aviatrix Gateway, where they get decrypted and reach the cloud instance. The response packets will take the same path backwards to the source VM in the datacenter.

Packet Datapath is represented by the blue dotted line in the diagram.

Real-world Considerations for Hyper-distributed Applications

With cloud adoption reaching a feverish pitch, enterprises’ business units are making independent decision on what cloud platform to use for their applications. The unintended consequence of this trend is that network architecture is an afterthought at best, or an impediment at worst.

To support this wave of innovation, network architects need to layout a Virtual Cloud Network strategy that can quickly connect new applications and microservices to other corporate resources no matter where they reside (Datacenter, remote offices, AWS, Azure, GCP, etc.)

There are two important considerations when planning a network for a hyper-distributed enterprise:

      1. Provide a multi-cloud network architecture where secure connectivity is flexible and ubiquitous.
      2. Maintain consistent security policies across hybrid and multiple clouds so that applications and users can be locked down to access only the resources they need.

Let’s look at both of these important considerations.

5.1 Connectivity Architecture of a Virtual Cloud Network

Aviatrix has developed an efficient, software-defined architecture that separates site-to-cloud transport connectivity from Cloud services connectivity to create a Virtual Cloud Network. The architecture is represented below:

Here are some of the key benefits of this Architecture:

      • Aligns teams and skills: DevOps and cloud teams have ownership of the shared service and spoke VPCs. This allows them to maintain agility and improves their self-sufficiency. The network team operates the hybrid transport.
      • Reduces egress charges: Intra-Cloud traffic in the service architecture level incurs half the egress charge compared to Transit VPC.
      • No performance bottlenecks: Inter-Cloud and Intra-Cloud traffic does not need to go through the Transit VPC.
      • Improves visibility and troubleshooting: Cloud teams gain visibility across hybrid and multi-cloud environments from a single, unified console.

5.2 Security Considerations for Hyper Distributed Applications

As application components continue to sprawl, it is important to keep security in the center of all decisions. Here are some key considerations:

      • Maintain Consistent Security Posture across your datacenter and public clouds. The centralized control model makes it possible to extract security groups and policies implemented within the NSX datacenter and push the same policies into the cloud. That way an AWS instance that belongs to an application group is governed by the same access rules as the VMware VMs in the same group.
      • Maintain Isolation by default: No traffic is allowed across networks unless specified by a security policy (configured in the Aviatrix Controller). This follows the zero-trust model preferred by InfoSec practitioners.
      • Encryption everywhere: Many enterprises’ regulatory requirements state that all data in motion needs to be encrypted.

To illustrate the concept of Consistent Security Posture across datacenters and Clouds, lets take an example of a billing application that has Application VMs in datacenter 1 and datacenter 2 that access a SQLServer Database in datacenter 1.

The security policy enforced in the NSX Distributed Firewall says that the Billing application VMs (defined as CorpBillingApp security group) can access the SQLServer (defined as SQLServer Security Group) over TCP port 1433. All other traffic is denied access to the SQLServer group.

Lets say, extension to this billing application are deployed across multiple public clouds. These new cloud instances need access to the same database in Datacenter 1. To enforce a consistent security policy across on-premise and the cloud, there needs to be a mechanism where the new cloud instances are added to the CorpBillingApp Security Group. This configuration should result in the access rule being extended to the cloud and enforced across the cloud and datacenters.

The following diagram illustrates the scenario:

Extending NSX security policy into the Cloud using Aviatrix

The Aviatrix Controller can be leveraged to implement consistent security policies into the cloud.

Let’s take a look at the configuration in NSX Manager UI. This is the screenshot of the security groups implemented in NSX. (CorpBillingAppVMs and SQLServer groups):


The Distributed Firewall policy in NSX enforces how CorpBillingAppVM group can access the SQLServer group:

Step 1: Extract the security policy from the NSX Manager. This can be done using API calls to the NSX Manager

Step 2: The database access policy should be pushed to the Aviatrix Controller by adding cloud instances to the CorpBillingAppVMs group (called Tag in Aviatrix). The following screenshot of the Aviatirx controller shows the policy configuration.

Step 3: The Aviatrix Controller automatically pushes the policy to the gateways. The gateways enforce this policy that results in the new cloud instances being able to access the SQLServer Database in Datacenter 1 over TCP port 1433.

Note: the “Deny all” option is checked in the Aviatrix Controller configuration. This will ensure that the gateways drop requests that do not comply.

Become the cloud networking hero of your business.

See how Aviatrix can increase security and resiliency while minimizing cost, skills gap, and deployment time.

Start For Free Get ACE Certified See Our Solutions
Learn
Build
Engage
Get Aviatrix updates and
customer newsletters