VMware Hands-on Labs - HOL-2122-01-NET


Lab Overview - HOL-2122-01-NET - NSX Cloud Consistent Networking and Security across Enterprise, AWS & Azure

Lab Guidance


Note: It will take more than 120 minutes to complete this lab. You should expect to only finish 2-3 of the modules during your time.  The modules are independent of each other so you can start at the beginning of any module and proceed from there. You can use the Table of Contents to access any module of your choosing.

The Table of Contents can be accessed in the upper right-hand corner of the Lab Manual.

VMware NSX Cloud provides customers the ability to abstract and manage Networking and Security policies in Public Cloud environments such as Amazon Web Services (AWS) and Microsoft Azure.

Through a scenario of an application deployed with minimal security in AWS and Azure, we will explore how VMware NSX Cloud provides operation consistency by bringing an existing cloud environment under NSX management and providing micro-segmentation to native workloads running in AWS and Azure.

Lab Module List:

  • Module 1 - Introduction to Public Cloud Environments  (30 minutes) Basic - In this module we will log in to the AWS and  Azure consoles to view the inventory of resources that have been  created. We will also review the configured application environment, verify application functionality, and review configured security  policies and posture.
  • Module 2 - Introduction to NSX Management Components  (15 minutes) Basic - In this module we will log in to On-premises  components like vCenter, NSX Manager and NSX Cloud Service Manager  (CSM) and explore the NSX Manager and NSX Cloud Services Manager capabilities and configuration.
  • Module 3 - Securing Native Cloud Applications with NSX  (60 minutes) Basic - In this module we will deploy and validate the  installation of NSX Public Cloud Gateway (PCG) in the AWS and Azure environments and secure the healthcare application OpenMRS with native security enforcement feature (agent-less).

Advance Module - Deploying NSX VPN to establish connectivity between On-Prem and Public Clouds:

  • Module 4 - Securing Hybrid Cloud Applications with NSX  (60 minutes) Advanced - In this module we will deploy and validate the  installation of NSX VPN between On-Prem and Public Clouds AWS & Azure and secure hybrid eCommerce applications ABCart running in On-premises, AWS and Azure with NSX security enforcement feature (agent).

 Lab Captains:

  • Puneet Chawla, Staff Solutions Architect, USA
  • Mohamad Haddad, Senior NSX Systems Engineer, UAE

This lab manual can be downloaded from the Hands-on Labs Document site found here:

http://docs.hol.vmware.com 

This lab may be available in other languages.  To set your language preference and have a localized manual deployed with your lab, you may utilize this document to help guide you through the process:

http://docs.hol.vmware.com/announcements/see-default-language.pdf


 

Location of the Main Console

 

  1. The area in the RED box contains the Main Console.  The Lab Manual is on the tab to the Right of the Main Console.
  2. A particular lab may have additional consoles found on separate tabs in the upper left. You will be directed to open another specific console if needed.
  3. Your lab starts with 90 minutes on the timer.  The lab can not be saved.  All your work must be done during the lab session.  But you can click the EXTEND to increase your time.  If you are at a VMware event, you can extend your lab time twice, for up to 30 minutes.  Each click gives you an additional 15 minutes.  Outside of VMware events, you can extend your lab time up to 9 hours and 30 minutes. Each click gives you an additional hour.

 

 

Alternate Methods of Keyboard Data Entry

During this module, you will input text into the Main Console. Besides directly typing it in, there are two very helpful methods of entering data which make it easier to enter complex data.

 

 

Click and Drag Lab Manual Content Into Console Active Window

You can also click and drag text and Command Line Interface (CLI) commands directly from the Lab Manual into the active window in the Main Console.  

 

 

Accessing the Online International Keyboard

 

You can also use the Online International Keyboard found in the Main Console.

  1. Click on the Keyboard Icon found on the Windows Quick Launch Task Bar.

 

 

Click once in active console window

 

In this example, you will use the Online Keyboard to enter the "@" sign used in email addresses. The "@" sign is Shift-2 on US keyboard layouts.

  1. Click once in the active console window.
  2. Click on the Shift key.

 

 

Click on the @ key

 

  1. Click on the "@ key".

Notice the @ sign entered in the active console window.

 

 

Activation Prompt or Watermark

 

When you first start your lab, you may notice a watermark on the desktop indicating that Windows is not activated.  

One of the major benefits of virtualization is that virtual machines can be moved and run on any platform.  The Hands-on Labs utilizes this benefit and we are able to run the labs out of multiple datacenters.  However, these datacenters may not have identical processors, which triggers a Microsoft activation check through the Internet.

Rest assured, VMware and the Hands-on Labs are in full compliance with Microsoft licensing requirements.  The lab that you are using is a self-contained pod and does not have full access to the Internet, which is required for Windows to verify the activation.  Without full access to the Internet, this automated process fails and you see this watermark.

This cosmetic issue has no effect on your lab.  

 

 

Look at the lower right portion of the screen

 

Please check to see that your lab is finished all the startup routines and is ready for you to start. If you see anything other than "Ready", please wait a few minutes.  If after 5 minutes you lab has not changed to "Ready", please ask for assistance.

 

Module 1 - Introduction to Public Cloud Environments (30 minutes)

Introduction


The NSX management and control plane components have been pre-deployed in our on-premises data center.

In the lab scenario, an application developer has also deployed two separate applications:

Healthcare Application name OpenMRS which is deployed natively in Public Clouds AWS and Azure.

eCommerce Application name AB-Cart which is a hybrid application as its web front-end tier is deployed in Public Clouds AWS & Azure but database and app tier is deployed on-Premises.

In this module we will see an overview of Virtual Network of Microsoft Azure and Amazon AWS. We will examine management console for public cloud accounts and verify their Inventory. We will also verify access to both application via their UIs.  Hybrid's application UI wont work at this point, as expected. It needs NSX VPN connectivity which we will establish in Module 5.


 

Healthcare Application OpenMRS Application Diagram - Native Public Cloud

 

OpenMRS has 2 tiers, Web and DB tier. Both tiers are running in public cloud (AWS & Azure).

 

 

eCommerce Application ABCart Application Diagram - Hybrid

 

ABCart has 3 tiers, Web, App, and DB tier. An instance of the front-end web service is deployed in public cloud (AWS & Azure). APP and DB services are deployed in our on-premises data center.

In order for the Hybrid application to fully function we need to  establish VPN from on-premises to the cloud providers.

 

Solution Overview


This lab includes many preconfigured items that are necessary for future lessons. We will examine a brief overview of the configured solution and review the functionality of the configured lab environment.

The configurations that will be reviewed include:

  • Lab topology
  • Lab provisioning status
  • Address and account information

 

Solution Overview

As companies move workloads to public cloud providers, they require a way to extend their SDDC network and security policies into these public environments. This extension allows workloads to run in public clouds with the same native controls they have present in an on-premises datacenter. VMware NSX Cloud provides companies with the ability to extend enterprise security, compliance and governance.

NSX provides solutions for the top networking and security challenges companies face in public cloud environments:

  • Inconsistent Network & Security Policies: NSX provides consistent constructs and policies across public clouds, using one UI and API entry point.
  • Security Policies are Cloud Specific: Each cloud provider supports their own unique requirements for policy definition. These can sometimes be static and unable to span virtual environments, regions, or across clouds. NSX supports dynamic security policies based on VM attributes, which can also span environments, regions, and public clouds.
  • Lack of Traffic Visibility: NSX provides traffic visibility using widely adopted technologies such as syslog, IPFIX, port mirroring, etc. Additional NSX tools such as Traceflow continue to work in public cloud environments.
  • Operational Tools and Processes: Existing tools and processes that just work with NSX can be leveraged across different public clouds, providing operational consistency.

 

 

Solution Components

 

The solution consists of the following components, each of which will be explored in upcoming lessons:

  • Management Plane - NSX Manager and NSX Cloud Services Manager
  • Control Plane - NSX Controllers
  • Cloud Gateway - NSX Public Cloud Gateway (PCG)
  • Data Plane - NSX Agent (optional)
  • Public Cloud Infrastructure - Public cloud infrastructure AWS and Azure

 

 

Public Cloud App (Healthcare OpenMRS) Topology

 

The picture depicts the environment that is provisioned and used during the lessons of this lab. The environment explores the scenario of a developer deploying an application with all components in public cloud, Microsoft Azure, and Amazon Web Services (AWS). The application deployment lacks security policies that match the company corporate standards, and it will be necessary to use NSX to apply consistent policies to the application environment.

 

 

Hybrid App (eCommerce AB-Cart) Topology

 

The picture depicts the environment that is provisioned and used during the lessons of this lab. The environment explores the scenario of a developer deploying an application with components in the on-premises data center, Microsoft Azure, and Amazon Web Services (AWS). The application deployment lacks security policies that match the company corporate standards, and it will be necessary to use NSX to apply consistent policies to the application environment.

The deployment of VMware NSX Cloud requires one or more Public Cloud environments. The NSX Management Plane (NSX-T Manager and Cloud Services Manager), these components have been pre-configured in the on-premises data center.

 

Lab Validation


This lab includes many pre-configured items that are necessary for future lessons. We will examine a brief overview of the configured solution and review the functionality of the configured lab environment.

The configurations that will be reviewed include:

  • Lab topology
  • Lab provisioning status
  • Address and account information

 

Lab Must Be In Ready State

 

Please check to see that your lab is finished all the startup routines and is ready for you to start. If you see anything other than "Ready", please wait a few minutes.  If after 5 minutes you lab has not changed to "Ready", please ask for assistance.

Proceeding when the lab is not "Ready" will result in a non-functional lab.

 

 

Lab provisioning status page

The AWS and Azure portions of the lab provisioning are currently completing. A webpage has been provided that displays the status of the lab resources that are being provisioned on AWS and Azure as part of this lab startup.

NOTE: The resources provisioned in Amazon Web Services and Microsoft Azure are accessible only from the Main Console of the HOL environment.

The lab provisioning can be expected to take 10-15 minutes.

 

 

Open Google Chrome

 

  1. Click on the Chrome Icon on the Windows Quick Launch Task Bar.

 

 

Account Information Homepage

 

The Chrome homepage has been set to the Account Information and lab provisioning status page.

  1. Type the Email Address you used to sign up for the lab.
  2. Type VMware1! for the Password.
  3. Click Login.

 

 

Lab Provisioning Complete

 

The Account Information page will display when the provisioning process is complete. This process can take 10 - 15 minutes. We will refer back to this page frequently in the lab modules.

 

Overview of Microsoft Azure Environment


We will review the Microsoft Azure application components that have been configured in the lab environment.


 

Transit Virtual Network

 

In the Transit VNET in Azure, the following components have been configured:

Azure Services

  • Uplink subnet (used by the NSX Cloud Gateway)
  • Management subnet (used by the NSX Cloud Gateway)
  • Downlink subnet (used by the NSX Cloud Gateway and where our application VM resides)
  • Azure Network Security Groups

Application web tier VM

  • ABCart-Web01-Azure

The NSX Cloud Gateway depicted will be deployed as part of the lab exercises.

In the Compute VNET in Azure, the following components have been configured:

Azure Services

  • Compute Subnet (Used to deploy the OpenMRS Web and OpenMRS DB)
  • We didn't deploy a PCG for Compute. We will leverage the same PCG in Transit to manage the Compute VNET. (This is why you see it linked to the Transit VNET)
  • Azure Network Security Groups

Application OpenMRS

  • OpenMRS-DB01-Azure
  • OpenMRS-Web01-Azure

The NSX Cloud Gateway depicted will be deployed as part of the lab exercises.

 

Perform log in to Microsoft Azure Portal


A web front end application virtual machine for this lab is running in Azure. Throughout this lab it will be necessary to access the Azure management console to verify inventory and configurations. This lesson will establish access to the Azure management console.


 

Accessing Azure Management Console

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the VMware Hands-On Labs bookmark.

 

 

Locate the Azure Management Console URL

 

  1. Click the Console URL to open a new browser tab and connect to the Azure Management Console.

 

 

Enter the Azure Email

 

  1. Copy or type the Azure account email address (Username) from the Account Information Page.
  2. Click Next.

 

 

 

Enter the Azure Password

 

  1. Copy or type the Azure account password from the Account Information Page.
  2. Click Sign In.

 

 

 

Do Not Remain Signed In

 

  1. If presented with this screen, Click No.

 

 

Azure Management Console

 

1. Press Close if you get this dialog from Azure

 

1. Press Close if you get any advertisement from Azure

The Azure management console page will appear as per the below screenshot.

 

 

Review of Microsoft Azure Inventory


In this lesson we will review the Microsoft Azure components that are part of the solution:

  • Virtual Network
  • Azure Network Security Groups
  • Virtual Machine (application web front end)

Please Note: Some Azure inventory screens may show deleted, terminated, detached, etc. entries that differ from the screenshots. These are items from the previous lab deployment that have been removed, but not yet cleared from, the Azure UI.


 

Review Configured Virtual Networks

 

  1. Click Virtual networks in the Azure management console.

If you don't see Virtual Networks please click "More Services" and then select Virtual Networks.

 

 

Review Configured Virtual Networks

 

There are two Virtual Network configured in this Azure Region where the application virtual machines are deployed.

  1. Click the Home link

 

 

Click Virtual Machines

 

  1. Click Virtual machines in the Azure console.

 

 

Review Azure Application VMs

 

There are multiple VMs running for this lab:

  • abCart-Web01-Azure: Hybrid Application web front end
  • OpenMRS-Web01-Azure: Native Public cloud application web front end
  • OpenMRS-DB01-Azure: Native Public cloud application DB back end

 

 

Select the Web VM

 

  1. Click the abCart-Web01-Azure virtual machine.

 

 

Click Networking

 

  1. Click Networking.

 

 

Configured Network Security Groups

 

A list of inbound policies that apply to this virtual machine are  displayed. Inbound Web traffic is allowed from the internet. All  traffic between virtual machines is allowed within the Virtual Network  environment.

 

1. Click Outbound port rules

The VM have been assigned to  "HOL-SecurityGroup". HOL-SecurityGroup network security group  is configured with inbound and outbound firewall rules.

A list of outbound policies that apply to this virtual machine are displayed. Outbound traffic from the VM is not allowed.

Any VM assigned this network security group will inherit these inbound/outbound firewall policies.

 

Validate Microsoft Azure Application


A web front end for the application has been deployed by a developer in Microsoft Azure. NSX will be used to secure this application in upcoming lessons. We will validate the pre-NSX functionality of the application.


 

Accessing Account Information

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the Account Info bookmark.

 

 

Locate the Web Instance Information

 

  1. Click on the Azure Web Frontend Instance Public URL link to open a new browser tab and connect to the application.

 

 

Verify ABcart Hybrid Application is Not Functioning

 

After a while the page will timeout and you will get "Gateway Time-Out" error. This is expected because the hybrid application is a 3-Tier application where the WebServer requires access to the APP. This access is not yet there because the VPN between the on-premises and the cloud is not yet established. 

 

 

OpenMRS Application (Native Azure Application)

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the Account Info bookmark.

Locate the Open MRS Web Instance Information

 

  1. Click on url to launch Openmrs application (Native public cloud).

 

 

Verify OpenMRS Application is Functioning

 

 

Overview of Amazon Web Services (AWS) Environment


We will review the Amazon Web Services application components that have been configured in the lab environment.


 

Transit VPC

 

In the Compute VPC in AWS, the following components have been configured:

AWS Services

  • Internet Gateway
  • Uplink subnet (used by the NSX Cloud Gateway)
  • Management subnet (used by the NSX Cloud Gateway)
  • Downlink subnet (used by the NSX Cloud Gateway and where our application instance resides)
  • AWS Security Groups

Application web tier instance

  • ABCart-Web01-AWS

The NSX Cloud Gateway depicted will be deployed as part of the lab exercises.

In the Compute VPC in AWS, the following components have been configured:

AWS Services

  • Compute Subnet (Used to deploy the OpenMRS Web and OpenMRS DB)
  • We didn't deploy a PCG for Compute. We will leverage the same PCG in Transit to manage the Compute VNET. (This is why you see it linked to the Transit VNET)
  • AWS Network Security Groups

Application OpenMRS

  • OpenMRS-DB01-AWS
  • OpenMRS-Web01-AWS

The NSX Cloud Gateway depicted will be deployed as part of the lab exercises.

 

Perform log in to AWS Management Console


A web front end application instance for this lab is running in Amazon Web Services. Throughout this lab it will be necessary to access the AWS management console to verify inventory and configurations. This lesson will establish access to the AWS management console.


 

Accessing AWS Management Console

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the VMware Hands-On Labs bookmark.

 

 

Locate the AWS Management Console URL

 

  1. Click the Console URL to open a new browser tab and connect to the AWS Management Console.

 

 

Log in to the AWS Console

 

  1. Type vmware_hol_user for the IAM User Name. Note: The Account ID will vary between lab environments.
  2. Type or copy the Password from the Account Information page.
  3. Click the Sign In button.

 

 

 

AWS Management Console

 

The AWS management console page will appear.

 

 

Zoom Browser

 

To improve readability of the various screens in this lab, it is recommended that you adjust the Zoom setting in Google Chrome to at least 90%.

  1. Click the Three Dots in the upper right hand corner of the browser for the drop down menu.
  2. Click '-' next to Zoom to adjust the setting to 90%.

 

 

Select Region

 

Verify that the console is viewing North California region resources. If a different region is selected the lab resources will not be displayed.

  1. Click the Region Name to the left of Support in the upper right.
  2. Select US West (N. California).

 

Review of Amazon Web Services (AWS) Inventory


In this lesson we will review the Amazon Web Services and NSX components that are part of the solution:

  • Virtual Private Clouds
  • AWS Security Groups
  • EC2 Instances (application web instance)

Please Note: Some AWS inventory screens may show deleted, terminated, detached, etc. entries that differ from the screenshots. These are items from the previous lab deployment that have been removed, but not yet cleared from, the AWS UI.


 

Review Configured Virtual Private Clouds

 

  1. Click Services in the upper left corner of the AWS management console.
  2. Click VPC under Network & Content Delivery.

 

 

Click Your VPCs

 

  1. Click Your VPCs under Virtual Private Cloud on the left.

 

 

Review Configured VPCs

 

There are two VPC's configured in this AWS Region where the application instance is deployed. The VPC's IDs will be different for each lab pod.

 

 

Click Security Groups

 

  1. Click on Security Groups on the left under Security.

 

 

Review Configured Security Groups

 

There are (4) Security Groups configured for the VPCs to allow EC2 instances to communicate in and out of the VPC's.  We will look at the configured rules in more depth in Module 2.

 

 

Click EC2

 

  1. Click Services in the upper left corner of the AWS console.
  2. Click EC2 under Compute.

 

 

Click Instances

 

  1. Click Instances under EC2 Dashboard on the left.

 

 

Review NSX EC2 Instances

 

There are multiple EC2 instances running for this lab:

  • ABCart-Web01-AWS: Hybrid Application web front end.
  • OpenMRS-Web01-AWS: Native Public cloud web front end.
  • OpenMRS-Db01-AWS: Native Public cloud DB backend.

 

 

Select the ab_cart-web01 Instance

 

  1. Select the ABCart_Web01-AWS instance.

 

  1. Click on the Instance ID for ABCart-Web

 

  1. Scroll down
  2. Select Security

 

1. Scroll Down

2. Applied Inbound Rules will appear

 

 

Check the Inbound Rules

 

  1. This instance has been configured with an AWS Security Group for the Compute-VPC.

 

 

Review the Configured AWS Security Policies

 

A list of policies that apply to this instance is displayed. Web and SSH  traffic are allowed from the any source. All traffic is allowed within  the AWS VPC environment.

 

Validate AWS Application


A web front end for the application has been deployed by a developer in Amazon Web Services. NSX will be used to secure this application in upcoming lessons. We will validate the pre-NSX functionality of the application.


 

Accessing Account Information

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the Account Info bookmark.

 

 

Locate the Web Instance Information

 

  1. Click on the AWS AB Cart Web Frontend Instance Public URL link to open a new browser tab and connect to the application.

 

 

Verify ABcart Hybrid Application is Functioning

 

After a while the page will timeout and you will get "Gateway Time-Out" error. This is expected because the hybrid application is a 3-Tier application where the WebServer requires access to the APP. This access is not yet there because the VPN between the on-premises and the cloud is not yet established.

 

 

Verify OpenMRS Native AWS Application

 

1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the Account Info bookmark.

Locate the Open MRS Web Instance Information

 

  1. Click on the AWS Open MRS Web Frontend Instance Public URL link to open a new browser tab and connect to the application.

 

 

Verify OpenMRS Application is Functioning

 

 

Conclusion


This completes Module 1. By successfully logging in to the management console of each location, we have reviewed the components of the solution that are deployed in our multi-cloud environment to support our application:

  • Microsoft Azure - An ABCart web front end virtual machine deployed in Transit VNet. Two OpenMRS virtual machines have been deployed in Compute VNet.
  • Amazon Web Services - An ABCart web front end virtual machine deployed in Transit VPC. Two OpenMRS virtual machines have been deployed in Compute VPC.

We have validated that the hybrid application is not yet functioning due to VPN connectivity, while the Native APP is functioning using the default native rules.


 

Congratulations, you've finished Module 1

Proceed to Module 2 for validation of the NSX Management Component. You may also proceed to any other module of interest.

  • Module 1 - Introduction to Public Cloud Environments  (30 minutes) Basic - In this module we will log in to the AWS and  Azure consoles to view the inventory of resources that have been  created. We will also review the configured application environment, verify application functionality, and review configured security  policies and posture.
  • Module 2 - Introduction to NSX Management Components  (15 minutes) Basic - In this module we will log in to On-premises  components like vCenter, NSX Manager and NSX Cloud Service Manager  (CSM) and explore the NSX Manager and NSX Cloud Services Manager capabilities and configuration.
  • Module 3 - Securing Native Cloud Applications with NSX  (60 minutes) Basic - In this module we will deploy and validate the  installation of NSX Public Cloud Gateway (PCG) in the AWS and Azure environments and secure the healthcare application OpenMRS with native security enforcement feature (agent-less).

Advance Module - Deploying NSX VPN to establish connectivity between On-Prem and Public Clouds:

  • Module 4 - Securing Hybrid Cloud Applications with NSX  (60 minutes) Advanced - In this module we will deploy and validate the  installation of NSX VPN between On-Prem and Public Clouds AWS & Azure and secure hybrid eCommerce applications ABCart running in On-premises, AWS and Azure with NSX security enforcement feature (agent).

 

Module 2 - Introduction to NSX Management Components (15 minutes)

Introduction


As part of the VMware NSX Cloud solution, separate virtual machines are deployed in our on-premises data center environment to support the Management and Operations User Interface for the solution. These instances are:

  • NSX Cloud Services Manager
  • NSX Manager

NSX Cloud Services Manager manages the complete lifecycle of deployed NSX components in AWS and Azure, and provides a unified view between NSX Manager and the public cloud inventory. Other functions of NSX Cloud Services Manager include:

  • NSX Cloud Gateway deployment and upgrades
  • NSX Tools upgrades via the NSX Cloud Gateway
  • Backup/Restore

NSX Manager provides the graphical user interface (GUI) and the REST APIs for creating, configuring, and monitoring NSX components such as the NSX controllers and logical switches. NSX Manager is the management plane for the NSX eco-system as it provides an aggregate view and is the centralized network management component of NSX.  From NSX manager you can monitor, troubleshoot and configure all networking and security  elements such as: 

  • Logical switching and routing
  • Networking and Edge services
  • Security services and distributed firewall

Lab Validation


This module requires Lab Status in Ready state and Microsoft Azure and Amazon Web Services Accounts information, in order to complete the lessons. We will take a few moments to validate this information.


 

Lab Must Be In Ready State

 

Please check to see that your lab has finished all the startup routines and is ready for you to start. If you see anything other than "Ready", please wait a few minutes.  If after 5 minutes you lab has not changed to "Ready", please ask for assistance.

Proceeding when the lab is not "Ready" will result in a non-functional lab.

 

 

Lab provisioning status page

The AWS and Azure portions of the lab provisioning are currently completing. A webpage has been provided that displays the status of the lab resources that are being provisioned on AWS and Azure as part of this lab startup.

NOTE: The resources provisioned in Amazon Web Services and Microsoft Azure are accessible only from the Main Console of the HOL environment.

The lab provisioning can be expected to take 10-15 minutes.

 

 

Open Google Chrome

 

  1. Click on the Chrome Icon on the Windows Quick Launch Task Bar.

 

 

Account Information Homepage

 

The Chrome homepage has been set to the Account Information and lab provisioning status page.

  1. Type the Email Address you used to sign up for the lab.
  2. Type VMware1! for the Password.
  3. Click Login.

 

 

Lab Provisioning Complete

 

The Account Information page will display when the provisioning process is complete. This process can take 10 - 15 minutes. We will refer back to this page frequently in the lab modules.

 

Perform log in to vCenter Environment


The on-premises data center environment contains both the NSX management and control plane components as well as various VMs for the application we will be securing in this lab.


 

On-Premises Topology

 

Our HOL vPod environment is acting as our on-premises data center environment. We have deployed the NSX Management and Control Plane components. Local NSX Edge is also deployed to act as the gateway for the local on-premises VMs and it will be used as a VPN server to build an IPSEC routed tunnel to both clouds AWS and Azure. In addition, we have also deployed the 4 application and database VMs that will support the front end web VMs that are running in our AWS and Azure environments. 

Note: The NSX deployment has been minimized for lab purposes only in order to reduce the lab start times. It is not a recommended or supported deployment model.

 

 

Open a new browser tab

 

  1. Click the Plus Sign in Google Chrome to open a new browser tab.

 

 

Open vCenter

 

  1. Click the vCenter bookmark.

 

 

Login to vCenter

 

  1. Click on "Open vmware-cip-launcher.exe"

 

  1. Click "Use Windows session authentication"
  2. Click Login.

 

 

Expand Inventory

 

  1. Click to expand RegionA01.
  2. Click to expand RegionA01-COMP01

We can see VMs are running in our on-premises data center.  The two on-premises application VMs have been deployed to serve the ABCart application.

 

Perform log in to NSX Cloud Services Manager


One function of the NSX Cloud Services Manager is to provide a unified view of the inventory between NSX and the public cloud environments. In this lesson we will log in to the NSX Cloud Services Manager.


 

Open a new browser tab

 

  1. Click the Plus Sign in Google Chrome to open a new browser tab.

 

 

NSX Cloud Services Manager Bookmark

 

  1. Click the CSM bookmark to connect to the NSX Cloud Services Manager console.

 

1. If you get the following warning click Advanced otherwise go to Login to NSX Cloud Service Manager.

 

1. Click Proceed to csm-01a.corp.local (unsafe)

 

 

Log in to NSX Cloud Services Manager

 

  1. Type admin for the Username.
  2. Type VMware1!VMware1! for the Password.
  3. Click Log In.

 

Review configured AWS account and inventory in CSM


NSX Cloud Service Manager provides a unified view of NSX and AWS inventory. We will review the inventory reported by NSX Cloud Service Manager and compare it to the AWS inventory.


 

CSM Configuration and Inventory

 

  1. Click Clouds.
  2. Click AWS.

 

 

Review AWS Account Information

 

The AWS account information has been configured in Cloud Services Manager.

This information may be different for each lab.

 

 

Review Number of Configured VPCs

 

As per the screenshot there are three VPCs configured in this AWS account, across the various Regions.

This information may be different for each lab.

 

 

Review Number of Configured Instances

 

The AWS EC2 instances for the applications that were reported in the AWS inventory are listed. The NSX State circle is not green because NSX components have not been deployed.

This example shows 3 instances running in this AWS account.

 

 

Click VPCs

 

  1. Click VPCs.

 

 

Review VPC's

 

This is the VPC's we saw in the AWS inventory in us-west-1 region in previous lessons.

 

 

Confirm VPC is not Managed by NSX

 

The Compute VPC reports a Status of "NSX Managed - No." Later in this lab we will deploy NSX components in this VPC to manage the running AWS EC2 instances.

 

 

Click Instances

 

  1. Click Instances.

 

 

Confirm Instances are not Managed by NSX

 

The AWS virtual machines for the applications that were reported in the AWS inventory are listed. The NSX State circle is not green because NSX components have not been deployed.

 

Review configured Azure account and inventory in CSM


NSX Cloud Service Manager provides a unified view of NSX and Azure inventory. We will review the inventory reported by NSX Cloud Service Manager and compare it to the Azure inventory.


 

CSM Configuration and Inventory

 

  1. Click Azure on the left.

 

 

Review Azure Account Information

 

The Azure account information has been configured in Cloud Services Manager. This information will be different for each lab pod.

 

 

Review Number of Configured VNets

 

There are two Virtual Networks configured in this Azure account.

 

 

Review Number of Configured Instances

 

There are 3 instances running in this Azure account.

 

 

Click VNets

 

  1. Click VNets.

 

 

Review VNet

 

These are the VNets we saw in the Azure inventory in previous lesson.

 

 

Confirm VNet is not Managed by NSX

 

The VNet reports a Status of "NSX Managed - No." Later in this lab we will deploy NSX components in this VNet to manage the running Azure virtual machines.

 

 

Click Instances

 

  1. Click Instances.

 

 

Confirm Instances are not Managed by NSX

 

The Azure virtual machines for the applications that were reported in the Azure inventory are listed. The NSX State circle is not green because NSX components have not been deployed.

 

Perform log in to NSX Manager


As the centralized management plane for the solution, we will be using NSX Manager to configure security policies for our application, as well as to validate the successful deployment of NSX in Amazon Web Services and Microsoft Azure. In this lesson we will log in to NSX Manager.


 

Open a new browser tab

 

  1. Click the Plus Sign in Google Chrome to open a new browser tab.

 

 

NSX Manager Bookmark

 

  1. Click the NSX-T Manager bookmark to connect to the NSX Manager console.

 

 

Log in to NSX Manager

 

  1. Type admin for the Username.
  2. Type VMware1!VMware1! for the Password.
  3. Click Log In.

 

Review NSX Manager User Interface


In preparation for the configuration of NSX to manage our application, we will walk through several of the NSX Manager User Interface screens to view the current configuration of the lab environment, validate that the NSX management infrastructure is functional, and get familiar with the new HTML5 interface.


 

Click Dashboard

 

  1. Click Monitoring Dashboards.
  2. Click System.

 

 

Management Cluster

 

The Dashboard screen provides a single location to see the status of the various components of the NSX deployment. You can see at a high level if there are any issues with components as well as things like the number of load balancers, firewall rules, and VPN sessions.

For our NSX deployment  we have deployed one instance of NSX Manager. We can see under System that the NSX Nodes is Green. This means that our NSX Manager/Controller node is up.

NSX Manager is the management plane component that provides the graphical user interface (GUI) and the REST APIs for creating, configuring, and monitoring NSX components such as controllers, logical switches, firewall policies, and edge service gateways.

NSX Controller is the control plane component that provides advanced distributed state management in our environment.

 

 

Review Fabric Status

There are 2 Host Transport Nodes in the NSX Fabric. We have  prepped both hosts for NSX.

 

 

 

 

Click Networking

 

  1. Click Networking on the top.
  2. Click Segments on the left.

 

 

Confirm Two Logical Segments in Inventory

There are two Logical segments that have been created. One overlay switch ABcart-PG for the on-premises VMs. The second is VLAN based for the NSX edge uplink that we will use for VPN termination, HOL-2122-EdgeUplink.

 

 

 

Click the Logical Segment

 

  1. Click the expand arrow.
  2. Click 2 in front of Ports.

 

 

Check out Logical Ports.

 

Both of our On-Prem virtual machines  (app01a and db01a) are connected to this segment.

 

Conclusion


This completes Module 2. By successfully logging in to the management console on-premises, we have reviewed the components of the  solution that are deployed in our on-premises environment to support our application:

  • On-premises data center - The NSX components and two ABCart application virtual machines are deployed (One App vm and one DB vm).

We have logged into the NSX Cloud Services Manager (CSM) that acts as the operations user interface for the VMware NSX Cloud solution. We also reviewed the AWS and Azure inventories from within NSX CSM. We have also logged into the NSX Manager and reviewed the inventory of NSX objects to confirm only the defaults are present and to get familiarity with the new HTML5 interface.


 

Congratulations, you've finished Module 2

Proceed to Module 3 to secure the native cloud application environment with NSX. You may also proceed to any other module of interest.

  • Module 1 - Introduction to Public Cloud Environments  (30 minutes) Basic - In this module we will log in to the AWS and  Azure consoles to view the inventory of resources that have been  created. We will also review the configured application environment, verify application functionality, and review configured security  policies and posture.
  • Module 2 - Introduction to NSX Management Components  (15 minutes) Basic - In this module we will log in to On-premises  components like vCenter, NSX Manager and NSX Cloud Service Manager  (CSM) and explore the NSX Manager and NSX Cloud Services Manager capabilities and configuration.
  • Module 3 - Securing Native Cloud Applications with NSX  (60 minutes) Basic - In this module we will deploy and validate the  installation of NSX Public Cloud Gateway (PCG) in the AWS and Azure environments and secure the healthcare application OpenMRS with native security enforcement feature (agent-less).

Advance Module - Deploying NSX VPN to establish connectivity between On-Prem and Public Clouds:

  • Module 4 - Securing Hybrid Cloud Applications with NSX  (60 minutes) Advanced - In this module we will deploy and validate the  installation of NSX VPN between On-Prem and Public Clouds AWS & Azure and secure hybrid eCommerce applications ABCart running in On-premises, AWS and Azure with NSX security enforcement feature (agent).

Module 3 and 4 are totally independent. If you want to deploy NSX for native application without NSX Tools/agent you can take module 3. If you want to deploy NSX for hybrid applications with NSX Tools/agent you can take module 4.

 

Module 3 - Securing Native Cloud Applications with NSX (60 minutes)

Introduction


Securing the application in Amazon Web Services (AWS), Microsoft Azure, and the on-premises data center requires security policies for the workloads that will be NSX managed. NSX provides a distributed firewall with logical grouping capabilities to simplify configuration and provide consistency.

After the Central Management Plane (NSX Manager and NSX Cloud Services Manager) have been deployed in the on-premises data center, the following steps are required to secure the application:

  1. An NSX Public Cloud Gateway (PCG) is deployed in each cloud environment.
  2. Link Transit-VPC and VNET to Compute VPC and VNET.
  3. A Cloud Administrator will create Logical Networks and Security Policies in NSX Manager UI or APIs.
  4. A Developer will apply the tags to their workloads in AWS and Azure for consumption of NSX policies at the time of instance creation.

NOTE: We deploy NSX Public Cloud Gateway in both public clouds (AWS and Azure) to showcase NSX Cloud capability to manage multi-clouds. One set of security policies created in NSX Manager gets pushed to all workloads running in On-premises, Amazon Azure (EC2), and Microsoft Azure.

If you interested in a specific Public Cloud provider feel free to skip the exercises that include the names of other public cloud provider.


 

Required Security Policies for Hybrid Application

 

The application requires these high level security policies.

 

Lab Validation


This module requires Lab Status in Ready state and Microsoft Azure and Amazon Web Services Accounts information, in order to complete the lessons. We will take a few moments to validate this information.


 

Lab Must Be In Ready State

 

Please check to see that your lab has finished all the startup routines and is ready for you to start. If you see anything other than "Ready", please wait a few minutes.  If after 5 minutes you lab has not changed to "Ready", please ask for assistance.

Proceeding when the lab is not "Ready" will result in a non-functional lab.

 

 

Lab provisioning status page

The AWS and Azure portions of the lab provisioning are currently completing. A webpage has been provided that displays the status of the lab resources that are being provisioned on AWS and Azure as part of this lab startup.

NOTE: The resources provisioned in Amazon Web Services and Microsoft Azure are accessible only from the Main Console of the HOL environment.

The lab provisioning can be expected to take 10-15 minutes.

 

 

Open Google Chrome

 

  1. Click on the Chrome Icon on the Windows Quick Launch Task Bar.

 

 

Account Information Homepage

 

The Chrome homepage has been set to the Account Information and lab provisioning status page.

  1. Type the Email Address you used to sign up for the lab.
  2. Type VMware1! for the Password.
  3. Click Login.

 

 

Lab Provisioning Complete

 

The Account Information page will display when the provisioning process is complete. This process can take 10 - 15 minutes. We will refer back to this page frequently in the lab modules.

 

Deploy NSX Cloud Gateway in Amazon Web Services


NSX components need to be deployed to provide security policies for the application instances in Amazon Web Services. The first step is to deploy the NSX Cloud Gateway in the Transit VPC where the ABCart application instance is also deployed.

As an Edge Transport Node in NSX, the NSX Cloud Gateway provides the following services in each VPC it is deployed:

  • Local control plane for both Native Enforced and NSX Enforced/Agented modes
  • Stateful services such as NAT, Edge Firewall, IPFix
  • Site-to-site IPsec VPN
  • Host and push NSX Tools/Agent software
  • Polls Amazon Web Services Tags

 

Open Google Chrome

 

  1. Click on the Chrome Icon on the Windows Quick Launch Task Bar (or open Chrome if it is already running).

 

 

Open a new browser tab

 

  1. Click the Empty Tab in Google Chrome to open a new browser tab (or switch to the CSM tab if it is already open).

 

 

NSX Cloud Services Manager Bookmark

 

  1. Click the CSM bookmark to connect to the NSX Cloud Services Manager console.

 

1. If you get the above warning click Advanced otherwise go to Login to NSX Cloud Service Manager

 

1. Click on Proceed to csm-01a.corp.local (unsafe)

 

 

Log in to NSX Cloud Services Manager

 

  1. Type admin for the Username.
  2. Type VMware1!VMware1! for the Password.
  3. Click Log In.

 

 

Select AWS Account

 

  1. Click Clouds.
  2. Click AWS.

 

 

Click VPCs

 

  1. Click VPCs at the top.

 

 

Narrow down the view of VPCs

 

  1. Select us-west-1 from the Region pull down menu to narrow down the view of VPCs

 

 

 

Click Actions Pull-Down Menu

 

  1. Click Actions in the Transit-VPC box.
  2. Click Deploy NSX Cloud Gateway.

 

 

Provide NSX Cloud Gateway Configuration Settings

 

  1. Close Information Box

 

  1. Click PEM File and select nsx-management.
  2. Enable Manage with NSX Tools
  3. Click Next.

 

 

Configure High Availability Settings

 

The NSX Cloud Gateway supports a High Availability (HA) deployment model. To reduce the amount of time it takes to complete the lab, we will not configure HA.

  1. Uncheck the Enable HA for NSX Cloud Gateway box.
  2. Select your Availability Zone us-west-1a OR us-west-1b. Note: AWS randomly assign availability zone. If you don't see us-west-1a, please select one of the two provided zones from drop down. If the wrong availability zone is selected, the subnet menus for steps 3-5 will be empty, in that case select the other availability zone.
  3. Select nsx-uplink-subnet for the Uplink Subnet.
  4. Select nsx-downlink-subnet for the Downlink Subnet.
  5. Select nsx-mgmt-subnet for the Management Subnet.
  6. Select Allocate new IP for the Public IP on Mgmt NIC
  7. Select Don't Allocate for the Public IP for Uplink NIC
  8. Click Deploy.

 

 

NSX Cloud Gateway Begins Deployment

 

The deployment process begins for this VPC. It can take approximately 7-10 minutes to complete. The deployment progress screen will report on the actions being completed in the process.

Deployment of the NSX Cloud Gateway provides the local control plane for NSX policies in this VPC.

 

  1. Click Finish

 

You will see that Gateway has been deployed. Also check NSX is managed by Gateway. Also Manage with Tools is On.

 

Linking Amazon Web Services VPC's


Important Note: Please make sure you have deployed NSX Cloud Gateway in Amazon Web Services before moving forward.


 

Log in to CSM

 

 

Log in to CSM.

  1. Type admin for the Username.
  2. Type VMware1!VMware1! for the Password.
  3. Click Log In.

NSX provides agentless solution for native enforcement. Below are the steps...

 

 

Select AWS Account

 

  1. Click Cloud.
  2. Click AWS.

 

 

Select VPCs

 

  1. Click VPCs from top menu.

 

 

Narrow down the view of VPCs

 

  1. Select us-west-1 from the Region pull down menu to narrow down the view of VPCs

 

For Compute-VPC

  1. Click on drop down arrow next to Actions.
  2. Select Link to Transit VPC for Compute-VPC

 

Close the Warning box

 

  1. Select Transit-VPC.
  2. Click Next.

 

 

1. Click Finish

 

Once you have linked Compute-VPC to Transit-VPC you can see NSX managed by Transit VPC.

 

Verify Amazon Web Services EC2 in NSX Manager


As the centralized management plane for the solution, we will be using NSX Manager to configure security policies for our application, as well as to validate the successful deployment of NSX in Amazon Web Services and Microsoft Azure. In this lesson we will log in to NSX Manager and verify public cloud instances in NSX Manager inventory.


 

Open a new browser tab

 

  1. Click the Plus Sign in Google Chrome to open a new browser tab.

 

 

NSX Manager Bookmark

 

  1. Click the NSX-T Manager bookmark to connect to the NSX Manager console.

 

 

Log in to NSX Manager

 

  1. Type admin for the Username.
  2. Type VMware1!VMware1! for the Password.
  3. Click Log In.

 

  1. Click on Inventory from top menu.

 

  1. Click on Virtual Machines

 

You should now see EC2 instances running in AWS under NSX manager inventory.

1. If you don't see the EC2 instance click refresh as per the screen shot. It takes few minutes for the inventory to be updated.

 

 

Deploy NSX Cloud Gateway in Microsoft Azure


NSX components need to be deployed to provide security policies for the application virtual machines in Microsoft Azure. The first step is to deploy the NSX Cloud Gateway in the Compute VNet where the ABCart application virtual machines are deployed.

As an Edge Transport Node in NSX, the NSX Cloud Gateway provides the following services in each VNet it is deployed:

  • Local control plane for NSX Tools
  • Stateful services such as NAT, Edge Firewall, IPFix
  • Site-to-site IPsec VPN
  • Host and push NSX Tools software
  • Polls Azure Tags

 

Log in to NSX Cloud Services Manager

 

  1. Click the Plus Sign in Google Chrome to open a new browser tab.

 

  1. Click the CSM bookmark to connect to the NSX Cloud Services Manager console.

 

  1. Type admin for the Username.
  2. Type VMware1!VMware1! for the Password.
  3. Click Log In.

 

 

Select Azure

 

  1. Click Clouds on the left.
  2. Click Azure on the left.

 

 

Click VNets

 

  1. Click VNets.

 

 

 

Click Actions Pull-Down Menu for HOL2122-Transit-vNET

 

  1. Click Actions.
  2. Click Deploy NSX Cloud Gateway.

 

 

Provide NSX Cloud Gateway Configuration Settings

 

 

 

  1. Copy the SSH Public Key from the very bottom of the Account Info web page (copy all three lines). Refer to Screenshot above.
  2. Change Manage with NSX Tool to Enabled.
  3. Change Auto-install NSX Tools to Enabled.
  4. Select the available option from the Local Storage Account option drop down menu.
  5. Click Next.

 

 

Configure High Availability Settings

 

The NSX Cloud Gateway supports a High Availability (HA) deployment model. To reduce the amount of time it takes to complete the lab, we will not configure HA.

  1. Uncheck the Enable HA for NSX Cloud Gateway box.
  2. Select nsx-uplink-subnet for the Uplink Subnet.
  3. Select nsx-downlink-subnet for the Downlink Subnet.
  4. Select nsx-mgmt-subnet for the Management Subnet.
  5. Select Allocate new IP for Public IP on Mgmt NIC.
  6. Select Don't Allocate for Public IP on Uplink NIC.
  7. Click Deploy.

 

 

NSX Cloud Gateway Begins Deployment

 

The deployment process begins for this VNet. It can take approximately 10-15 minutes to complete. The deployment progress screen will report on the actions being completed in the process.

Deployment of the NSX Cloud Gateway provides the local control plane for NSX policies in our VNet.

Continue to the next lesson to configure Create NSX Firewall Rules while the NSX  Cloud Gateway deployment completes. We will then return to NSX Cloud  Services Manager to verify completion...

 

  1. Click Finish.

 

You will see that Gateway has been deployed. Also check NSX is managed by Gateway. Also Manage with NSX Tools and Auto-install NSX Tools are On.

 

Create NSX Firewall Rules in NSX Manager


NSX Distributed Firewall provides security enforcement for workloads in public cloud. In this section we will configure firewall rules in NSX distributed firewall.


 

NSX Distributed Firewall

Log into NSX Manager.

 

 

 

  1. Username is admin.
  2. Password is VMware1!VMware1!
  3. Click on Log IN.

 

 

  1. Click on Security.
  2. Click on Distributed Firewall on left.
  3. Click on ADD POLICY.

 

 

  1. Click on New Policy to change name of policy. Change name to OpenMRS-Policy.

 

 

  1. Click on three dots next to OpenMRS-Policy.

 

 

  1. Click on Add Rule.

 

 

 

Change the name of Rule: Web to DB.

 

 

  1. Click the Pencil Icon to edit the Sources.

 

 

  1. Enter openmrs in search bar.
  2. Select OpenMRS-Web group.
  3. Click Apply.

 

 

  1. click on Edit icon next to destination.

 

 

  1. Enter openmrs in search bar.
  2. Select OpenMRS-DB group.
  3. Click Apply.

 

 

  1. Click on edit icon next to Services.

 

 

  1. Enter mysql in search bar.
  2. Select MySQL service.
  3. Click Apply.

 

 

  1. Click Edit Applied To. This field is used to define scope of Firewall Rules.

 

 

  1. Select Groups.
  2. Enter openmrs in search bar.
  3. Select OpenMRS group.
  4. Click Apply.

This will ensure that this rules get applied to all virtual machines which are part of OpenMRS group which is both web and db servers.

 

 

  1. Click on 3 dots next to Web to DB rule.
  2. Select Add Rule.

 

 

  1. Change name of rule to Internet to Web.
  2. Click on edit under destination.

 

  1. Enter openmrs in bar above.
  2. Select OpenMRS-Web.
  3. Select Apply.

 

 

  1. Edit Services.

 

 

  1. Enter HTTP in search bar.
  2. Select HTTP as service.
  3. Click APPLY.

 

 

  1. Click on Edit icon next to Applied To.

 

 

  1. Select Groups.
  2. Enter openmrs in search bar.
  3. Select OpenMRS group.
  4. Click Apply

 

 

 

Verify OpenMRS-Policy and Publish

 

 

  1. Click Publish

 

Linking Microsoft Azure VNET's


Important Note: Please make sure you have deployed NSX Cloud Gateway in Azure before moving forward.


 

Log into Cloud Services Manager

 

 

  1. Click on Azure.

 

Click on VNets.

 

  1. Once you are on Compute-vNET, click on Actions.
  2. Select Link to Transit VNet.

 

Close the warning box

 

  1. Select Transit-vNET.
  2. Click Next.

 

 

  1. Click Finish

 

Once you have linked Compute-vNET to Transit-vNET you can see NSX Manager by Transit VNet.

 

Verify Microsoft Azure VMs in NSX Manager


As the centralized management plane for the solution, we will be using NSX Manager to configure security policies for our application, as well as to validate the successful deployment of NSX in Amazon Web Services and Microsoft Azure. In this lesson we will log in to NSX Manager and verify public cloud instances in NSX Manager inventory.


 

Open a new browser tab

 

  1. Click the Empty Tab in Google Chrome to open a new browser tab.

 

 

NSX Manager Bookmark

 

  1. Click the NSX-T Manager bookmark to connect to the NSX Manager console.

 

 

Log in to NSX Manager

 

  1. Type admin for the Username.
  2. Type VMware1!VMware1! for the Password.
  3. Click Log In.

 

  1. Click on Inventory from top menu.

 

  1. Click on Virtual Machines

 

You can see Virtual Machines running in Azure under NSX manager virtual machine inventory.

 

Verify tags for cloud VMs


In order to save lab time we have pre created the tags in AWS and Azure. In this exercise we will verify those tags.


 

Verify Tags to EC2 instances in AWS

Log into AWS Management Console. Credentials are provided in Hands on Labs callback page.

 

 

 

  1. Click Services.
  2. Click EC2.

 

  1. Under Resources you will see that there are total (4) EC2 instances running.

 

  1. Select OpenMRS-web01-AWS vm.

 

  1. Click on Tags.

Verify pre created tags App-Name: openmrs and App-Tier: web

Repeat the same steps for OpenMRS-db01-AWS EC2 instance also.

 

Verify pre created tags App-Name: openmrs and App-Tier: db

 

 

Verify Tags to Azure Virtual Machines

  1. Log back into Azure Portal

 

 

Please click on Virtual Machines from top menu.

 

You will see all virtual machines. Please click on OpenMRS-Web01-Azure.

 

Click on Tags from side menu.

 

Verify pre created tags App-Name: openmrs and App-Tier: web

Repeat the same steps for OpenMRS-DB01-Azure VM also.

 

Verify pre created tags App-Name: openmrs and App-Tier: db

 

Verify Grouping in NSX Manager


In this section we will review NSX groups created based on tags defined in previous sections. You will see how these tags are dynamically discovered by NSX Manager and these virtual machines are assigned to NSX groups based on tags and scope.


 

Verify Groups in NSX

Log into NSX Manager

 

Username: admin

Password: VMware1!VMware1!

 

 

  1. Click on Inventory.
  2. Click on Groups.

 

Search openmrs in search bar.

 

In the interest of time we have already created groups for our application (OpenMRS) which will leverage Native Security Enforcement. We will review these Groups and also review its member group definition.

 

 

 

Review OpenMRS Group

 

Click on View Members.

Review Virtual Machines. Here you will see all VM's running in both AWS and Azure.

 

Next we will review Group membership criteria (Group Definition). Here you will see that we are using AppName tag as membership criteria for both AWS and Azure. These are discovered automatically from virtual machines running. These are the tags we had verified in previous section.

 

1. Click on Group Definition and you will see that it is based on Tag equal to OpenMRS and Scope equal to App-Name (discovered from both AWS and Azure).

 

 

Review OpenMRS Web Frontend Group

 

Click on View Members.

 

You can see Web server from both AWS and Azure here. This provides consistent security policy to workloads running in both AWS and Azure.

 

Check out IP Address tab. It shows IP address of both virtual machines. 172.16.x.x is running in AWS and 172.19.x.x. in Azure.

 

  1. Click on Group Definition.
  2. Review App-Tier and App-Name tags.

 

1. Clicl Close once done.

 

 

Review OpenMRS DB Backend Group

 

  1. Click on View Members in front of OpenMRS-DB group.

 

You will see both DB machines running in AWS and Azure in this group. Next we will review group definition.

 

  1. Click on Group Definition.
  2. Review App-Tier and App-Name tags.

 

1. Click Close one done.

 

Test Native Cloud Application



 

Log into Hands on Labs landing Page

 

You will see login credentials for both Open MRS AWS and Azure.

 

 

Click on AWS Open MRS Frontend URL.

 

Log into using below credentials.

  1. Username: Admin
  2. Password: VMware1!

 

You will see login page of application. Click on Administration.

 

Your application is working properly.

 

Test NSX Native Firewall Enforcement


In this section we will perform NSX Native Firewall enforcement. This is an agentless approach to enforce security using native security constructs of public cloud. We will perform steps on OpenMRS our native public cloud application.


 

Log into NSX Manager

 

Log into NSX manager with below credentials.

  1. Username: admin
  2. Password: VMware1!VMware1!

 

  1. Click on Security tab at the top.

 

  1. Click on Distributed Firewall.

You will be able to see firewall rules  created under OpenMRS Policy section.

 

OpenMRS Policy is allowing HTTP communication and MySql between Web and DB tier. Also note that source and destination are groups we created earlier. This way we can leverage same and consistent security policy across both public clouds.

To test security policies, go ahead and change action to Reject.

 

  1. Change Internet to Web policy action to Reject.
  2. Click Publish.

 

 

Application Connectivity Verification from Azure Portal

Log into your Azure Dashboard using credentials for Hands on Lab.

 

 

  1. Click on Virtual Machines.

 

Click on OpenMRS-DB01-Azure virtual machine.

 

  1. Click on Networking on left side.
  2. Click on Inbound Port Rules.
  3. Check Rule 101, Deny rule for port 80 which got created.

 

 

Application Connectivity Verification from UI

 

Go back to open tab VMware Hands-on Lab in Chrome.

 

Click on Azure Open MRS Web Frontend URL.

 

As you can see application is not working and now Web VM is not reachable.

 

Conclusion


This completes Module 3. The Healthcare OpenMRS application that was deployed in our public cloud environment has been successfully secured by installing NSX Public Cloud Gateway in Amazon Web Services and Microsoft Azure. We have applied consistent security policies to the application instances.

  • Deployed Public Cloud Gateway on Transit VPC and VNet on Public Clouds
  • Linked Compute VPC and VNet with Transit
  • Created NSX firewall rules (DFW) in NSX Manager
  • Verified NSX firewall enforcement in Azure VM and AWS EC2 instance

 

Congratulations, you've finished Module 3

You may finish the lab now or proceed to advanced networking Module 4 to deploy NSX VPN for Hybrid Cloud application's networking and security with NSX.

  • Module 1 - Introduction to Public Cloud Environments  (30 minutes) Basic - In this module we will log in to the AWS and  Azure consoles to view the inventory of resources that have been  created. We will also review the configured application environment, verify application functionality, and review configured security  policies and posture.
  • Module 2 - Introduction to NSX Management Components  (15 minutes) Basic - In this module we will log in to On-premises  components like vCenter, NSX Manager and NSX Cloud Service Manager  (CSM) and explore the NSX Manager and NSX Cloud Services Manager capabilities and configuration.
  • Module 3 - Securing Native Cloud Applications with NSX  (60 minutes) Basic - In this module we will deploy and validate the  installation of NSX Public Cloud Gateway (PCG) in the AWS and Azure environments and secure the healthcare application OpenMRS with native security enforcement feature (agent-less).

Advance Module - Deploying NSX VPN to establish connectivity between On-Prem and Public Clouds:

  • Module 4 - Securing Hybrid Cloud Applications with NSX  (60 minutes) Advanced - In this module we will deploy and validate the  installation of NSX VPN between On-Prem and Public Clouds AWS & Azure and secure hybrid eCommerce applications ABCart running in On-premises, AWS and Azure with NSX security enforcement feature (agent).

 

Module 4 - Securing Hybrid Cloud Applications with NSX (60 minutes)

Introduction


NOTE: This Module is advance level and requires networking background to deploy and configure Site-2-Site Route based VPN between On-premises and Public Clouds.

NOTE: We deploy NSX VPN in both public clouds (AWS  and Azure) to showcase NSX Cloud capability to manage multi-clouds. One set of security policies created in NSX Manager gets pushed to all the workloads running in On-premises, Amazon Azure (EC2), and Microsoft Azure.

If you are interested in a specific Public Cloud provider feel free to skip the exercises that include the names of other public cloud provider.

Securing the application in Amazon Web Services (AWS), Microsoft Azure, and the on-premises data center requires security policies for the workloads that will be NSX managed. NSX provides a distributed firewall with logical dynamic grouping capabilities to simplify configuration and provide consistency.

After the Central Management Plane (NSX Manager and NSX Cloud Services Manager) have been deployed in the on-premises data center, the following steps are required to secure the application:

  1. An NSX Cloud Gateway is deployed in each cloud environment with workloads to be managed by NSX.
  2. VPN Is configured between the on-premises Edge router and the PCG in the cloud.
  3. BGP is configured between the on-premises Edge router and the PCG in the cloud to advertise both the the on-premises segments and cloud subnets dynamically.
  4. A Cloud Administrator will create Logical Networks and Security Policies using the NSX Manager UI or APIs.
  5. A Developer will apply the tags to their workloads in AWS and Azure for consumption of NSX policies at the time of instance creation.
  6. The NSX Tools is installed on each AWS instance and Azure virtual machine to be managed by NSX.

 

Required Security Policies for Hybrid Application

 

The application requires these high level security policies.

 

Lab Validation


This module requires Lab Status in Ready state and Microsoft Azure and Amazon Web Services Accounts information, in order to complete the lessons. We will take a few moments to validate this information.


 

Lab Must Be In Ready State

 

Please check to see that your lab has finished all the startup routines and is ready for you to start. If you see anything other than "Ready", please wait a few minutes.  If after 5 minutes you lab has not changed to "Ready", please ask for assistance.

Proceeding when the lab is not "Ready" will result in a non-functional lab.

 

 

Lab provisioning status page

The AWS and Azure portions of the lab provisioning are currently completing. A webpage has been provided that displays the status of the lab resources that are being provisioned on AWS and Azure as part of this lab startup.

NOTE: The resources provisioned in Amazon Web Services and Microsoft Azure are accessible only from the Main Console of the HOL environment.

The lab provisioning can be expected to take 10-15 minutes.

 

 

Open Google Chrome

 

  1. Click on the Chrome Icon on the Windows Quick Launch Task Bar.

 

 

Account Information Homepage

 

The Chrome homepage has been set to the Account Information and lab provisioning status page.

  1. Type the Email Address you used to sign up for the lab.
  2. Type VMware1! for the Password.
  3. Click Login.

 

 

Lab Provisioning Complete

 

The Account Information page will display when the provisioning process is complete. This process can take 10 - 15 minutes. We will refer back to this page frequently in the lab modules.

 

Deploy NSX Cloud Gateway in Amazon Web Services


Important Note: If you have already deployed the Public Cloud Gateway in AWS (from Module 3), skip to here.

NSX components need to be deployed to provide security policies for the application instances in Amazon Web Services. The first step is to deploy the NSX Cloud Gateway in the Transit VPC where the ABCart application instance is also deployed.

As an Edge Transport Node in NSX, the NSX Cloud Gateway provides the following services in each VPC it is deployed:

  • Local control plane for both Native Enforced and NSX Enforced/Agented modes
  • Stateful services such as NAT, Edge Firewall, IPFix
  • Site-to-site IPsec VPN
  • Host and push NSX Tools/Agent software
  • Polls Amazon Web Services Tags

 

Open Google Chrome

 

  1. Click on the Chrome Icon on the Windows Quick Launch Task Bar (or open Chrome if it is already running).

 

 

Open a new browser tab

 

  1. Click the Empty Tab in Google Chrome to open a new browser tab (or switch to the CSM tab if it is already open).

 

 

NSX Cloud Services Manager Bookmark

 

  1. Click the CSM bookmark to connect to the NSX Cloud Services Manager console.

 

1. If you get the above warning click Advanced otherwise go to Login to NSX Cloud Service Manager

 

1. Click on Proceed to csm-01a.corp.local (unsafe)

 

 

Log in to NSX Cloud Services Manager

 

  1. Type admin for the Username.
  2. Type VMware1!VMware1! for the Password.
  3. Click Log In.

 

 

Select AWS Account

 

  1. Click Clouds.
  2. Click AWS.

 

 

Click VPCs

 

  1. Click VPCs at the top.

 

 

Narrow down the view of VPCs

 

  1. Select us-west-1 from the Region pull down menu to narrow down the view of VPCs

 

 

 

Click Actions Pull-Down Menu

 

  1. Click Actions in the Transit-VPC box.
  2. Click Deploy NSX Cloud Gateway.

 

 

Provide NSX Cloud Gateway Configuration Settings

 

  1. Close Information Box

 

  1. Click PEM File and select nsx-management.
  2. Enable Manage with NSX Tools
  3. Click Next.

 

 

Configure High Availability Settings

 

The NSX Cloud Gateway supports a High Availability (HA) deployment model. To reduce the amount of time it takes to complete the lab, we will not configure HA.

  1. Uncheck the Enable HA for NSX Cloud Gateway box.
  2. Select your Availability Zone us-west-1a OR us-west-1b. Note: AWS randomly assign availability zone. If you don't see us-west-1a, please select one of the two provided zones from drop down. If the wrong availability zone is selected, the subnet menus for steps 3-5 will be empty, in that case select the other availability zone.
  3. Select nsx-uplink-subnet for the Uplink Subnet.
  4. Select nsx-downlink-subnet for the Downlink Subnet.
  5. Select nsx-mgmt-subnet for the Management Subnet.
  6. Select Allocate new IP for the Public IP on Mgmt NIC
  7. Select Don't Allocate for the Public IP for Uplink NIC
  8. Click Deploy.

 

 

NSX Cloud Gateway Begins Deployment

 

The deployment process begins for this VPC. It can take approximately 7-10 minutes to complete. The deployment progress screen will report on the actions being completed in the process.

Deployment of the NSX Cloud Gateway provides the local control plane for NSX policies in this VPC.

 

  1. Click Finish

 

You will see that Gateway has been deployed. Also check NSX is managed by Gateway. Also Manage with Tools is On.

 

Configure VPN for Amazon Web Services



 

Logical Network/VPN Topology

 

The hybrid App have the web server hosted in AWS cloud. In order to test the hybrid app, the Web server requires reachability to the on-premises APP server, ABCart-App01a. We will use the NSX PCG deployed in AWS transit VPC to establish a VPN connection between the on premises NSX edge and the PCG in AWS cloud.

  1. When PCG is deployed in the transit VPC the process creates a T0 router in NSX.
  2. Every managed AWS VPC is represented with a T1 router in NSX. When an EC2 instance get managed by NSX its subnet automatically gets connected to the VPC T1 router.
  3. In this lab, we have pre-configured another T0 and T1 on the local edge for the local segment.

These T0 routers are used to establish VPN. The T0 routers have a private IP reserved for VPN. In this chapter, we will associate the VPN private IP address with a pre-populated public IP named "NSX-VPN-PublicIP" in AWS to establish a VPN over the internet with the on-premises T0.

Similarly, the local T0 have a private IP address 192.168.110.112 for VPN. This VPN private will be NATed to a public IP in the HOL network.  This public IP is the vAPP IP noted in the account information page.

Without NSX there will be more complex steps to establish the secure connectivity between the on-premises environment and the cloud providers.

Security team will have to:

  • Deploy a third party VM based firewall  or deploy an AWS gateway in the cloud.
  • Configure VPN between their legacy physical firewall and VM based firewall or gateway in the cloud.

Network team will have to:

  • Configure route tables in AWS in every VPC to route traffic via the VM firewall or AWS gateway.
  • Configure routing on their core switch/routers with the firewalls and NSX on-premises edge.

As you can see from the above tasks, you will have multiple touch points to get the cloud connectivity up and running. Thus, visibility and troubleshooting becomes more complex in multi-cloud environment.

NSX simplifies configuration using a single pane of glass to manage network and security. You don't need to deploy a VM based firewall, cloud gateway or route tables in the cloud. This reduces required resources and OPEX in the cloud.

Please note that the IP Addresses in the screen shots may differ from the ones you will see in your lab. This is expected as some IP addresses are dynamically assigned.

 

 

Login to  AWS Management Console

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the Account Info bookmark.

 

  1. Click the Console URL to open a new browser tab and connect to the AWS Management Console.

 

  1. Type vmware_hol_user for the IAM User Name.
  2. Type or copy the Password from the Account Information Page.
  3. Click Sign in

 

 

Public Cloud Gateway (PCG) is assigned three private IP addresses on the uplink interface. The third IP is reserved for VPN termination. In order to establish a VPN connection between On-Prem Edge and PCG we will associate the third private IP address with a public IP. 

Before associating the public IP address we will need to identify the Uplink Interface ID of the PCG. In the below steps you will copy the interface ID. In the next steps, we will associate the VPN private IP with a public IP.

 

  1. Click on Services.
  2. Click on EC2.

 

  1. Click Instances.

 

  1. Select the NSX PCG.

 

  1. Go to Actions
  2. Go to Networking
  3. Go to Manage IP Addresses

 

  1. Scroll down to reach the last Interface.
  2. This is the uplink interface for the PCG. It has three private IP addresses. The third IP is the one reserved for VPN.

NOTE: The private IP may be different for your lab as its dynamically assigned.

 

1. Select the interface ID

2. Right Click and Copy the Interface ID

 

1. Click Cancel

 

 

In the previous step we have copied the interface ID of the PCG uplink interface. We have seen that it has three private IP addresses associated where the third one is for VPN. In this section we will assign a public IP to that VPN Private IP address. This public IP will be used for establishing VPN between the on-premises Edge and the PCG in the cloud.

Public IP addresses in AWS are called elastic IP addresses. We have a pre-populated one elastic IP named NSX-VPN-PublicIP that is available for association. We will associate it with the VPN Private IP on the PCG Uplink.

 

  1. Go To Services
  2. Go to VPC under Networking & Content Delivery

 

  1. Click on Elastic IPs.

 

  1. Select the NSX-VPN-PublicIP. The available IP is not associated to any interface ID.
  2. Click on Actions
  3. Click Associate Elastic IP Address

 

  1. Select Network Interface
  2. Paste the Interface ID we copied in the step before and select it from the list

 

  1. Go to Private IP Address and select the last IP address in the list
  2. Click Associate

Note: Your lab might have a different IP addresses as they are dynamically assigned.

 

The private IP is now associated to the Public IP address. We will use the Public IP address to establish the VPN. In the next steps, the VPN Private IP will be used as the Local endpoint identity for AWS PCG.

Please keep this website open so we can come back and copy these IPs for the VPN IPSEC session configuration

 

 

 

1. Click the Empty Tab in Google Chrome to open a new browser tab

 

1. Click the NSX-T Manager bookmark to connect to the NSX-T Manager console.

 

  1. Username is: admin.
  2. Password is: VMware1!VMware1!
  3. Click on: Log IN

 

 

Enable IPSEC On AWS T0 Router

When PCG is deployed in the transit VPC the process creates a T0 router in NSX. In this lab, we have pre-configured another T0 on the local edge. These T0 routers are the ones that will establish VPN. In the next chapter, we will use the same routers to run BGP to dynamically advertise the networks connected to them.

The first thing to do on NSX side is to enable VPN on both T0 routers. In this section, we will enable VPN on the AWS T0. To save some time and effort the VPN has already been enabled on the local T0 router.  

 

1. Go to Networking

2. Click on VPN

3. Click on VPN Services

4. Click ADD Service and Select IPSEC

 

1. Enter the IPSEC Name: AWS-PCG-T0

2. From the Tier0/Tier1 Gateway drop menu select AWS T0. The AWS T0 have "vpc" in the name.

3. Click Save

Note that the AWS T0 have the word "vpc" in the name. This is how you can distinguish AWS T0s from Azure T0s.

 

1. Click No.

 

 

Configure Local Endpoint for AWS PCG

After enabling VPN on T0 the second step is to add all VPN peers to NSX. VPN peers are called Local Endpoints in NSX. An IPSEC Site-to-Site session have two peers. In our lab the peers are the T0 routers. The first peer is the local T0 which is running on the local on-premises edge. The second peer is the T0 running on AWS PCG.

Each peer is identified by a unique IP address. For AWS T0 it will be the VPN Private IP of PCG uplink. For on-premises T0 we use the private IP 192.168.110.112 . To save some time and effort we have already added the local T0 as an local endpoint in NSX. In this section, we will add the AWS T0 as a local endpoint.  

 

  1. Go back to the AWS Page that we left open and copy the private IP Address

 

  1. Go to back to NSX and click Local Endpoints tab.
  2. Click Add Local Endpoint

 

  1. Enter the name: AWS-PCG-LE
  2. Select the AWS PCG-T0 from the drop down list. This is AWS T0 which will be one peer of the IPSEC tunnel termination.
  3. Paste the Private IP address we copied before
  4. Click Save

Please make sure when you paste the Private IP there is no space before or after the IP

 

1. Click Refresh to make sure the configuration is successful.

 

 

About IPSEC Sessions

After enabling IPSEC on the T0 and adding the IPSEC peers to NSX, we need to configure the IPSEC session between the two peers. Since both peers are part of NSX, we will have to configure the site-to-site tunnel from both ends. Which means we will create two unidirectional tunnels. One from AWS T0 to local T0 and the other  from local T0 to AWS. To accomodate the HOL networking, we have configured the local T0 to be the initiator of the session and AWS will be the responder, similar to client to server VPN.

To save time and effort the session from the local T0 is already configured  with dummy IPs. We will  need to update the Remote IP and Remote ID.  

 

 

Copy vAPP Public IP

The vAPP public IP is the on-premises Edge public IP which we will use to establish VPN with AWS.

 

  1. Go to the Account Information Page and copy the vAPP public IP.

 

 

Configure IPSEC session from AWS T0 to Local T0

Navigate back to NSX Manager Tab and follow the below steps.

 

  1. Go to IPSEC Sessions
  2. Click Add IPSEC Session
  3. Select Route Based.

We have selected route based VPN because will be running BGP routing protocol on top of the IPSEC session. This will create a tunnel interface for BGP.

 

  1. Enter a name for the session: AWS-OnPrem
  2. Select AWS-PCG-T0 for VPN Service
  3. Select AWS-PCG-LE for Local Endpoint
  4. Paste the vAPP Public IP we have copied before in the "Remote IP" field
  5. Enter a tunnel IP: 172.17.2.2/24. This is the tunnel interface which we will use to run BGP.
  6. Enter Remote ID: 192.168.110.112. This is the Identity for the local on-premises T0.
  7. Enter Pre-Shared Key: VMware1!
  8. Click on Advanced Properties

Please make sure when you paste the Remote IP there is no space before or after the IP

 

  1. Select Respond Only for Connection Initiation
  2. Enable TCP MSS Clamping
  3. Select Both for TCP MSS Direction

 

  1. Click Save

 

 

Configure IPSEC session from Local T0 to AWS T0

 

  1. Go back to the AWS Page that we left open. Highlight the Public IP Address, right click it and copy it

 

  1. Go back to NSX Manager click Networking
  2. Click on VPN
  3. Click on IPSEC Sessions
  4. You will find the OnPrem-AWS session already configured.

 

  1. Click on the 3 dots near OnPrem-AWS and select Edit

 

  1. Paste the Public IP that we copied from AWS in "Remote IP" field replacing the dummy IP 1.1.1.1.

 

  1. Go to back to AWS tab Highlight the Private IP Address, right click it and copy it
  2. Right click and copy

 

  1. Go to NSX Manager and paste the private IP we copied from AWS In the "Remote ID" field. This is the AWS T0 Identity IP which we have configured in the previous step.
  2. Click Save

As you can see from the above screen the other side of the tunnel interface have been configured with 172.17.2.1/24. Both tunnel interfaces are on the same subnet. We will use these IP addresses to establish the BGP session in the next chapter.

 

  1. Click on the arrow to collapse the VPN configuration.

 

  1. Click Refresh icon near each VPN Session. You wil see the VPN on AWS and Local Edge changes to Success.

You may need to click the refresh icons multiple times. If the VPN doesn't go up after 1 minute please review the steps again to verify the configuration and IP addresses.

 

Configure BGP for Amazon Web Services



 

Configure BGP

This chapter requires basic knowlege of BGP and routing.

BGP Routing Topology

 

In the previous chapter we have created two unidirectional VPN sessions. We have selected route based VPN in order to create a tunnel interface for BGP. In this section we will configure BGP on both sides, on AWS and local edge. We will use the VPN tunnel interface created during the IPSEC session in previous chapter to establish  the BGP.  

  1. The On-Premises T0 is running BGP AS 65000
  2. The On-Premises T0 BGP Tunnel Interface is configured with IP Address: 172.17.2.1/24
  3. The AWS T0 is running BGP AS 65002
  4. The AWS T0 BGP Tunnel Interface is configured with IP address: 172.17.2.2/24

We will configured both as BGP neighbors to establish the BGP session over the tunnel interface.

 

 

Configure BGP on AWS T0

 

  1. Go to Networking
  2. Tier-0 Gateways
  3. Click on AWS T0.  AWS T0 have "vpc" in its name.

Please note that the AWS T0 have "vpc" in the name of the T0. This is how you distinguish AWS T0 from Azure T0.

 

  1. Click 3 Dots and select Edit

 

  1. Scroll Down to BGP Section
  2. Enter the BGP Local AS Number: 65002
  3. Enable BGP
  4. Click Save

 

  1. Click Set Under Neighbors

 

  1. Click Add BGP Neighbor

 

  1. Enter the BGP Neighbor: 172.17.2.1 (This is the on-premises T0 IP Address)
  2. Enter the Remote AS Number: 65000 (This is the on-premises T0 AS number)
  3. Click Save

 

  1. Click Refresh to verify the configuration has been initialized.
  2. Click Close

Please don't close the BGP dialog and continue to the next section Route Redistribution.

 

 

Route Redistribution

Redistribution Topology

 

Every AWS VPC is represented with a T1 router in NSX. When any VM in the VPC is managed by NSX the VM subnet will be automatically connected to the VPC T1 router. By design, T1 and T0 connected segments are not advertised via BGP unless explicitly defined via a redistribution policy on T0 routers running BGP. In this section, we will define a redistribution policy to advertise T1 and T0 connected segments into BGP. This will dynamically advertise all T0 and T1 connected segments into BGP. This step is done once and as you continue adding subnets in the future they get advertised automatically.

To save time and effort BGP redistribution policy has  already been configured on the local T0. In this section, you will configure redistribution on AWS T0 Only.

 

  1. Click on Route Re-Distribution
  2. Click Set

 

  1. Click ADD Route Re-Distribution

 

  1. Give it a name: Connected-To-BGP
  2. Click Set

 

  1. Under Tier-0 Subnets Select "Connected Interfaces & Segments"
  2. Under Tier-1 Subnets Select "Connected Interfaces & Segments"
  3. Click Apply

 

  1. Click ADD

 

  1. Click APPLY

 

  1. Click Save

 

  1. Click Close Editing

 

 

Configure BGP on Local T0

 

  1. Click the 3 dots near the Local Edge T0 HOL-2122-T0

 

  1. Click select Edit

 

  1. Scroll Down to BGP sections. BGP has been already enabled with AS 65000.
  2. Click "Set" near BGP Neighbors to add new neighbor

 

  1. Click ADD BGP Neighbor

 

  1. Enter the Neighbor IP: 172.17.2.2 (This is the AWS T0 IP Address))
  2. Enter AS Number: 65002 (This is the AWS T0 AS number)
  3. Click Save

 

  1. Click Refresh

 

  1. BGP should be IP click "i" beside the Success Message

 

  1. 1. Make sure it is in ESTABLISHED state
  2. Click Close

 

  1. Click Close

 

  1. Click Close Editing

 

Configure Forwarding Policy for Amazon Web Services



 

Configure Forwarding Policy

 

The current web server hosted in the cloud have two gateways. The first gateway is AWS gateway and this is referred to as underlay gateway in NSX. The second gateway is NSX T1 gateway and this referred to as overlay gateway in NSX. NSX tools installed on the VM controls the routing from the VM. This is called forwarding policy in NSX. Forwarding policy is similar to policy based routing in traditional networks.

The default forwarding policy in NSX depicts that only traffic going to AWS services or other VPCs to use AWS gateway/underlay. All other traffic should be routed to the PCG/Overlay. Since our WebServer in the cloud is already assigned a public IP address we want to modify the forwarding policy as follows:

  1. Traffic from the VM destined to the on-premises segments to use the T1 Router/Overlay. Based on the routing the traffic will then go via the VPN tunnel.
  2. All other traffic such as internet or AWS services/VPCs to use the AWS Gateway/Underlay.

In this section, we will be configuring the forwarding policy as described above.

Navigate back to NSX Manager

 

1. Click Networking

2. Click Forwarding Policies

3. Click on the Forwarding Policy for AWS. AWS Forwarding policy has "vpc" in its name.

AWS Forwarding Policy have "vpc" in the name of the policy. This is how to distinguish AWS from Azure policy.

 

1. Click on the 3 dots and select Add Rule

 

1. Ener the name: AWS-HOL2122

 

1. In order not to create a new group, please drag and drop the source group from the last rule to the newly created rule

 

1. In the destination click Edit (pencil icon)

 

1. Enter HOL to filter the groups

 

1. Select HOL2122-Local-Segments

2. Select Apply

 

1. Change the Policy to Route to Overlay

 

1. Go to the Default routing policy and change the forwarding to Route to Underlay.

 

1. Click Publish

 

Installation of NSX Tools in EC2 Instance Amazon Web Services


To continue the process of securing the web frontends, the NSX Tools/Agent must be deployed. The NSX Tools provides the data plane functions within each Amazon Web Services instance or Microsoft Azure virtual machine where it is installed. This includes:

  • Distributed firewall enforcement engine
  • Tunnel endpoint for overlay networking

A best practice would be to include the agent in the "Golden Image", custom and IT approved images that are used in an organization's public cloud environment. The NSX Tools can also be installed in existing deployed, or brownfield, instances using a variety of automation methods.

The NSX Tools will be deployed on each of the web frontends. For AWS, we'll show a manual approach where we will install NSX Tools on an EC2 instance by running a single bash script. For Azure instance NSX Tools install process is been automated, as we have enable "Auto-install NSX Tool" setting previously during the deployment of the gateway.


 

Copy ABCart WEB01 Public IP

Go to AWS Console Tab in browser (previously open)

 

1.Click on Services

2.Click EC2

 

1. Click on Instances

 

1. Click on ABCart-Web01-AWS Instance ID

 

1. Right click and Copy the Public IPv4 Address

 

 

New PuTTY Session

 

  1. Click on the PuTTY Icon in the upper left of the open PuTTY session.

 

 

SSH Into AWS Web Frontend

 

1. Right Click and Paste the Public IP

 

1. Click on SSH

2. Select Auth

3. Click Browse

 

1. Select SecurityKey Directory

 

 

1. Select the nsx-compute.ppk File

2. Click Open

1. Click Open

 

 

Verify Connection

 

The first time connecting to the instance will result in a confirmation window to verify the connection.

  1. Click Yes.

 

  1. Username: ubuntu
  2. Enter

We have used the private key in putty session which gets you authenticated automatically once you enter username.

 

 

Install the NSX Tools on AWS

Go to CSM tab in browser (previously open)

 

 

 

  1. Click on AWS under clouds on left side.
  2. Click on VPCs.

 

 

  1. Click anywhere on the Transit-VPC tile.

 

 

Scroll below under Overview to NSX Tool Download & Installation. There you will see steps to install NSX Tools/agent.

  1. Select and Copy the link from Download Location for Linux OS

 

 

NOTE: Please use the download location provided in your Transit-VPC. Below URL is just for example as IP address is dynamic.

From the SSH session of ABCart-Web01-AWS vm download NSX Tool via wget to the url provided in your Transit-VPC. Following is the example:

wget http://172.15.20.168:8080/factory_default/linux/install_nsx_vm_agent.sh

 

Install NSX Tools by executing following command:

  • chmod +x install_nsx_vm_agent.sh && sudo ./install_nsx_vm_agent.sh

NOTE: The NSX Tools installation can take 3-5 minutes to complete.

 

 

NSX Tools has been installed.

 

Applying Tags to the Amazon Web Services Application


NSX-specific Tags are used to indicate where the EC2 instance's network interface should be logically "attached" in NSX. During attachment, security policies are pushed. Prior to enabling the NSX Tools on the web frontend, we will configure a Tag.


 

Accessing AWS Management Console

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the Account Info bookmark.

 

 

Locate the AWS Management Console URL

 

  1. Click the Console URL to open a new browser tab and connect to the AWS Management Console.

 

 

Log in to the AWS Console

 

  1. Type vmware_hol_user for the IAM User Name.
  2. Type or copy the Password from the Account Information Page.
  3. Click the Sign In button.

 

 

 

Select Region

 

Verify that the console is viewing North California region resources.

  1. Click the Region Name to the left of Support in the upper right.
  2. Select US West (N. California).

 

 

Navigate to EC2 Instances

 

  1. Click Services in the upper left corner of the AWS console.
  2. Click EC2 under Compute.

 

 

Click Instances

 

  1. Click Instances in the menu on the left.

 

 

Acknowledge UI Changes

 

  1. If presented to you, click the X to close out the notification.

 

 

Expand Column

 

  1. Click and Drag the column handle to expand the Name column.

 

 

Select the Web instance

 

  1. Select ABCart-Web01-AWS EC2 instance

 

 

Click the Tags tab for this instance

 

  1. Click the Tags tab below the list of EC2 instances.
  2. Click Add/Edit Tags.

 

 

Click Create Tag

 

  1. Click Create Tag.
  2. Type nsx.network under Key.
  3. Type default under Value. (Note: Do not use the auto-complete DEFAULT-nsx-compute-security-group that may appear)
  4. Click Save.

 

 

Summary

We have applied the NSX-specific Tag to the web frontend. Once the NSX Tool is deployed, this tag will "attach" the instance to the default NSX Logical Switch that was created during the NSX Cloud Gateway deployment. Security policies will also be applied to this instance.

 

Deploy NSX Cloud Gateway in Microsoft Azure


Important Note: If you have already deployed the Public Cloud Gateway in Azure (from Module 3), skip to here.

NSX components need to be deployed to provide security policies for the application virtual machines in Microsoft Azure. The first step is to deploy the NSX Cloud Gateway in the Compute VNet where the ABCart application virtual machines are deployed.

As an Edge Transport Node in NSX, the NSX Cloud Gateway provides the following services in each VNet it is deployed:

  • Proxy (local) control plane for NSX Tools/Agents
  • Stateful services such as NAT, Edge Firewall, IPFix
  • Site-to-site IPsec VPN
  • Host and Push NSX Tools software
  • Polls Azure Tags

 

Select Azure

 

  1. Click Clouds on the left.
  2. Click Azure on the left.

 

 

Click VNets

 

  1. Click VNets.

 

 

 

Click Actions Pull-Down Menu for HOL2022-Transit-vNET

 

  1. Click Actions.
  2. Click Deploy NSX Cloud Gateway.

 

 

Provide NSX Cloud Gateway Configuration Settings

 

 

 

  1. Copy the SSH Public Key from the very bottom of the Account Info web page (copy all three lines). Refer to Screenshot above.
  2. Change Manage with NSX Tool to Enabled.
  3. Change Auto-install NSX Tools to Enabled.
  4. Select the available option from the Local Storage Account option drop down menu.
  5. Click Next.

 

 

Configure High Availability Settings

 

The NSX Cloud Gateway supports a High Availability (HA) deployment model. To reduce the amount of time it takes to complete the lab, we will not configure HA.

  1. Uncheck the Enable HA for NSX Cloud Gateway box.
  2. Select nsx-uplink-subnet for the Uplink Subnet.
  3. Select nsx-downlink-subnet for the Downlink Subnet.
  4. Select nsx-mgmt-subnet for the Management Subnet.
  5. Select Allocate new IP for Public IP on Mgmt NIC.
  6. Select Don't Allocate for Public IP on Uplink NIC.
  7. Click Deploy.

 

 

NSX Cloud Gateway Begins Deployment

 

The deployment process begins for this VNet. It can take approximately 10-15 minutes to complete. The deployment progress screen will report on the actions being completed in the process.

Deployment of the NSX Cloud Gateway provides the local control plane for NSX policies in our VNet.

 

 

You will see that Gateway has been deployed. Also check NSX is managed by Gateway. Also Manage with NSX Tool and Auto-install NSX Tool are On.

 

Configure VPN for Microsoft Azure


Logical Network/VPN Topology

 

The hybrid App have the web server hosted in Azure cloud. In order to test the hybrid app, the Web server requires reachability to the on-premises APP server, ABCart-App01a. We will use the NSX PCG deployed in Azure transit VPC to establish a VPN connection between the on premises NSX edge and the PCG in Azure cloud.

  1. When PCG is deployed in the transit VNET the process creates a T0 router in NSX.
  2. Every Azure VPC is represented with a T1 router in NSX. When any VM in the VPC is managed by NSX the VM subnet will be automatically connected to the VNET T1 router.
  3. In this lab, we have pre-configured another T0 and T1 on the local edge for the local segment.

These T0 routers are used to establish VPN. The T0 routers have a private IP reserved for VPN. In this chapter, we will associate the VPN private IP address with a pre-populated public IP named NSX-VPN-PublicIP in Azure to establish a VPN over the internet with the on-premises T0.

Similarly, the local T0 have a private IP address 192.168.110.112 for VPN. This VPN private will be NATed to a public IP in the HOL network.  This public IP is the vAPP IP noted in the account information page.

Without NSX there will be more complex steps to establish the connectivity between the on-premises environment and the cloud providers.

Security team will have to:

  • Deploy a third party VM based firewall  or deploy an Azure gateway in the cloud.
  • Configure VPN between their legacy physical firewall and VM based firewall or gateway in the cloud.

Network team will have to:

  • Configure route tables in Azure in every VNET to route traffic via the VM firewall or Azure gateway.
  • Configure routing on their core switch/routers with the firewalls and NSX on-premises edge.

As you can see from the above tasks, you will have multiple touch points to get the cloud connectivity up and running. Thus, visibility and troubleshooting becomes more complex in multi-cloud environment.

NSX simplifies configuration using a single pane of glass to manage network and security. You don't need to deploy a VM based firewall, cloud gateway or route tables in the cloud. This  reduces required resources and OPEX in the cloud.

Please note that the IP Addresses in the screen shots may differ from the ones you will see in your lab. This is expected as these IP addresses are dynamically assigned.


 

Login to Azure Portal

Log into Azure Management Console. Credentials are provided in Hands on Labs callback page.

 

  1. Click the Console URL to open a new browser tab and connect to the Azure Management Console.

 

  1. Copy or type the Azure account email address from the Account Information Page.
  2. Click Next.

 

  1. Copy or type the Azure account password from the Account Information Page.
  2. Click Sign In.

 

  1. If presented with this screen, Click No.

 

  1. If you get the above dialog click Close.

 

  1. If you get any advertisement from Azure click Close.

 

The Azure management console page will appear as per the below screenshot.

 

 

Public Cloud Gateway (PCG) is assigned three private IP addresses on the uplink interface. The third IP is reserved for VPN termination. In order to establish a VPN connection between On-Prem Edge and PCG we will associate the VPN Private IP address with a public IP. We have a pre-populated two Public IPs name NSX-VPN-PublicIP and NSX-Uplink0-Primary-PublicIP that are available for association. We will associate it with the VPN Private IPs on the PCG Uplink.

 

  1. Go to the top search window and search for uplink0. Uplink0 is the NSX PCG uplink interface.
  2. Click on the uplink interface. It always starts with nsx-gw-"Subscription ID"

 

  1. Click on IP Configurations

 

 

 

  1. Click on "primary".

 

  1. Click on "Associate"
  2. Click on "Choose public IP address"

 

  1. Select the NSX-Uplink0-Primary-PublicIP
  2. Select Save

 

  1. Once association is done. Click the Network Interface Link at the top.

 

 

 

  1. Click on "vpn-secondary-ip". The uplink have three IP addresses. The third IP is reserved for VPN and has a private IP only.

 

  1. Click on Associate
  2. Click on Choose public IP address

 

  1. Select the NSX-VPN-PublicIP
  2. Click Save

 

Notice the notification from Azure that Network Changes are getting saved. Usually, this takes around a minute to finish.

 

Notice the Network changes have been completed

 

  1. Click the Network Interface Link at the top

 

The private IP is now associated to the Public IP address. We will use the Public IP address to establish the VPN. In the next steps, the VPN Private IP will be used as the Local endpoint identity for Azure PCG.

Please keep this page open as we will revert back to it to copy the private IP and public IP for VPN configuration.

 

 

Login to NSX Manager

Log into NSX Manager

 

  1. Click the Empty Tab in Google Chrome to open a new browser tab

 

  1. Click the NSX-T Manager bookmark to connect to the NSX-T Manager console.

 

  1. Username is: admin.
  2. Password is: VMware1!VMware1!
  3. Click on: Log IN.

 

 

Enable IPSEC on Azure T0 Router

When PCG is deployed in the transit VNET the process creates a T0 router in NSX. In this lab, we have pre-configured another T0 on the local edge. These T0 routers are the ones that will establish VPN. In the next chapter, we will use the same routers to run BGP to dynamically advertise the networks connected to them.

The first thing to do on NSX side is to enable VPN on both T0 routers. In this section, we will enable VPN on the Azure T0. To save some time and effort the VPN has already been enabled on the local T0 router.  

 

  1. Go to Networking
  2. Click on VPN
  3. Click on VPN Services
  4. Click ADD Service
  5. Select IPSEC

 

  1. Enter the IPSEC Name: Azure-PCG-T0
  2. From the Tier0/Tier1 Gateway drop menu select Azure T0. Azure T0 doesn't have "vpc" in the name.
  3. Click Save

Note that the Azure T0 doesn't have the word "vpc" in the name. This is how you can distinguish AWS T0s from Azure T0s.

 

  1. Click No.

 

 

Configure Local Endpoint for Azure PCG

After enabling VPN on T0 the second step is to add all VPN peers to NSX. VPN peers are called Local Endpoints in NSX. An IPSEC Site-to-Site session have two peers. In our lab the peers are the T0 routers. The first peer is the local T0 which is running on the local on-premises edge. The second peer is the T0 running on Azure PCG.

Each peer is identified by a unique IP address. For Azure T0 it will be the VPN Private IP of PCG uplink. For on-premises T0 we use the private IP 192.168.110.112 . To save some time and effort we have already added the local T0 as an local endpoint in NSX. In this section, we will add the Azure T0 as a local endpoint.  

 

  1. Go back to the Azure tab that we left open and Select the private IP
  2. Right click and copy the private IP Address

 

  1. Go to NSX Manager Networking Tab
  2. Click VPN
  3. Click Local Endpoints
  4. Click Add Local Endpoint

 

  1. Enter the name: Azure-PCG-LE
  2. Select the Azure-PCG-T0 from the drop down list. This is Azure T0 which will be one side of the IPSEC tunnel termination.
  3. Paste the Private IP address we copied before
  4. Click Save

Please make sure when you paste the Private IP there is no space before or after the IP

 

 

About IPSEC Sessions

After enabling IPSEC on the T0 and adding the IPSEC peers to NSX, we need to configure the IPSEC session between the two peers. Since both peers are part of NSX, we will have to configure the site-to-site tunnel from both ends. Which means we will create two unidirectional tunnels. One from Azure T0 to local T0 and the other  from local T0 to Azure. To accomodate the HOL networking, we have configured the local T0 to be the initiator of the session and Azure will be the responder, similar to client to server VPN.

To save time and effort the session from the local T0 is already configured  with dummy IPs. We will  need to update the Remote IP and Remote ID.  

 

 

Copy the vAPP Public IP

The vAPP public IP is the on-premises Edge public IP which we will use to establish VPN with Azure.

 

  1. Go to the Account Information tab and copy the vAPP public IP.

 

 

Configure IPSEC session from Azure T0 to Local T0

Navigate back to NSX Manager Tab and follow the below steps.

 

  1. Go to Networking
  2. Click on VPN
  3. Click IPSEC Sessions

 

 

  1. Click Add IPSEC Session
  2. Select Route Based

We have selected route based VPN because will be running BGP routing protocol on top of the IPSEC session. This will create a tunnel interface for BGP.

 

  1. Enter a name for the session: Azure-OnPrem
  2. Select Azure-PCG-T0 for VPN Service
  3. Select Azure-PCG-LE for Local Endpoint
  4. Paste the vAPP Public IP we have copied before in the "Remote IP" field
  5. Enter a tunnel IP: 172.17.1.2/24. This is the tunnel interface which will use to run BGP.
  6. Enter Remote ID: 192.168.110.112. This is the Identity for the local on-premises T0.
  7. Enter Pre-Shared Key: VMware1!
  8. Click on Advanced Properties

Please make sure when you paste the Remote IP there is no space before or after the IP

 

  1. Select Respond Only for Connection Initiation
  2. Enable TCP MSS Clamping
  3. Select Both for TCP MSS Direction
  4. Click Save

 

 

Configure IPSEC session from Local T0 to Azure T0

 

  1. Go Back Azure tab that we left open and right click the public IP and copy it

 

Go Back NSX Manager tab

  1. Click on IPSEC Sessions. In order to safe time we have already created IPSEC session OnPrem-Azure.
  2. Click on the 3 dots for OnPrem-Azure and select Edit.

 

  1. Paste the Public IP that we copied from Azure in the "Remote IP" field replacing the dummy IP 2.2.2.2.

 

  1. Go to Azure tab select the private IP
  2. Right click and copy

 

  1. Go back to NSX Manager and paste the private IP we copied from Azure into the "Remote ID" field. This is the Azure T0 Identity IP which we have configured in the previous step.
  2. Click Save

As you can see from the above screen the other side of the tunnel interface have been configured with 172.17.1.1/24. Both tunnel interfaces are on the same subnet. We will use these IP addresses to establish the BGP session.

 

  1. Click on the arrow to minimize the configuration

 

  1. Click Refresh icon near the Azure VPN sessions.
  2. You wil see the VPN on Azure and Local Edge change to Success.

You may need to click the refresh icons multiple times. If the VPN doesn't go up after 1 minute please review the steps again to verify the configuration and IP addresses.

 

Configure BGP for Microsoft Azure



 

Configure BGP

This chapter requires basic knowlege of BGP and routing.

BGP Routing Topology

 

In the previous chapter we have created two unidirectional VPN sessions. We have selected route based VPN in order to create a tunnel interface for BGP. In this section we will configure BGP on both sides, on Azure and local edge. We will use the VPN tunnel interface created during the IPSEC session in previous chapter to establish  the BGP.  

  1. The On-Premises T0 is running BGP AS 65000
  2. The On-Premises T0 BGP Tunnel Interface is configured with IP Address: 172.17.1.1/24
  3. The Azure T0 is running BGP AS 65001
  4. The Azure T0 BGP Tunnel Interface is configured with IP address: 172.17.1.2/24

We will configured both as BGP neighbors to establish the BGP session over the tunnel interface.

 

 

Configure BGP on Azure T0

 

1. Go to Networking

2. Tier-0 Gateways

3. Click on Azure T0. Azure T0 doesn't have "vpc" in the name.

Please note that the Azure T0 doesn't have "vpc" in the name of the T0. This is how you distinguish Azure T0 from AWS T0.

 

1. Click Edit

 

1. Scroll Down to BGP Sections

2. Enter the BGP Local AS Number: 65001

3. Enable BGP

4. Click Save

 

1. Click "Set" or "1" Under Neighbors

 

1. Click Add BGP Neighbor

 

1. Enter the BGP Neighbor: 172.17.1.1 (This is the on-premises T0 IP Address)

2. Enter the Remote AS Number: 65000 (This is the on-premises T0 AS number)

3. Click Save

 

1. Click Refresh to verify the configuration has been initialized.

2. Click Close

Please don't close the BGP dialog and continue to the next section Route Redistribution.

 

 

Route Redistribution

Redistribution Topology

 

Every Azure VNET is represented with a T1 router in NSX. When any VM in the VNET is managed by NSX the VM subnet will be automatically connected to the VNET T1 router. By design, T1 and T0 connected segments are not advertised via BGP unless explicitly defined via a redistribution policy on T0 routers running BGP. In this section, we will define a redistribution policy to advertise T1 and T0 connected segments into BGP. This will dynamically advertise all T0 and T1 connected segments into BGP. This step is done once and as you continue adding subnets in the future they get advertised automatically.

To save time and effort BGP redistribution policy has  already been configured on the local T0. In this section, you will configure redistribution on Azure T0 Only.

 

1. Expand  Route Re-Distribution

2. Click Set

 

1. Click ADD Route Re-Distribution

 

1. Give it a name: Connected-To-BGP

2. Click Set

 

1. Under Tier-0 Subnets Select "Connected Interfaces & Segments"

2. Under Tier-1 Subnets Select "Connected Interfaces & Segments"

3. Click Apply

 

1. Click ADD

 

2. Click APPLY

 

1. Click Save

 

1. Click Close Editing

 

1. Click on the Arrow to collapse the configuration

 

 

Configure BGP on Local T0

 

1. Click the Local Edge T0 HOL-2122-T0

 

2. Click 3 dots and select Edit

 

1. Scroll Down to BGP sections. BGP has been already enabled with AS 65000.

2. Click Set "1"near BGP Neighbors to add new neighbor

 

1. Click ADD BGP Neighbor

 

1. Enter the Neighbor IP: 172.17.1.2 (This is the Azure T0 IP Address)

2. Enter AS Number: 65001 (This is the Azure T0 AS number)

3. Click Save

 

1. Click Refresh

 

1. BGP should be UP. Click "i" beside the Success Message.

 

1. Make sure it is in ESTABLISHED state

2. Click Close

 

1. Click Close

 

1. Click Close Editing

 

Configure Forwarding Policy for Microsoft Azure



 

Configure Forwarding Policy

 

The current web server hosted in the cloud have two gateways. The first gateway is Azure gateway and this is referred to as underlay gateway in NSX. The second gateway is NSX T1 gateway and this referred to as overlay gateway in NSX. NSX tools installed on the VM controls the routing from the VM. This is called forwarding policy in NSX. Forwarding policy is similar to policy based routing in traditional networks.

The default forwarding policy in NSX depicts that only traffic going to Azure services or other VNETs to use Azure gateway/underlay. All other traffic should be routed to the T1/Overlay. Since our WebServer in the cloud is already assigned a public IP address we want to modify the forwarding policy as follows:

  1. Traffic from the VM destined to the on-premises segments to use the T1/Overlay. Based on the routing the traffic will then go via the VPN tunnel.
  2. All other traffic such as internet or Azure services/VNETs to use the Azure Gateway/Underlay.

In this section, we will be configuring the forwarding policy as described above.

Navigate back to NSX Manager

 

1. Click Networking

2. Click Forwarding Policies

3. Click on the Forwarding Policy for Azure. The forwarding policy for Azure doesn't have "vpc" in the name.

Azure Forwarding Policy don't have "vpc" in the name of the policy. This is how to distinguish Azure from AWS policy.

 

1. Click Add Rule

 

1. Ener the name: Azure-HOL2122

1. In order not to create a new group, please drag and drop the source group from the last rule to the newly created rule

 

1. In the destination click Edit

 

1. Enter HOL to filter the groups

 

1. Select HOL2122-Local-Segments

2. Click Apply

 

1. Click On Action

2. Change the Policy to Route to Overlay

 

1. Go to the Default routing policy and change the action to Route to Underlay.

 

1. Click Publish

 

Applying Tags to the Microsoft Azure Application


NSX-specific Tags are used to indicate where the virtual machine's network interface should be logically "attached" in NSX. During attachment, security policies are pushed. Prior to enabling the NSX Tool on the web front end, we will configure a Tag.


 

Accessing Azure Portal

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the Account Info bookmark.

 

 

Locate the Azure Portal URL

 

  1. Click the Console URL to open a new browser tab and connect to the Azure Management Console.

 

 

Enter the Azure Email

 

  1. Copy or type the Azure account email address from the Account Information Page.
  2. Click Next.

 

 

 

Enter the Azure Password

 

  1. Copy or type the Azure account password from the Account Information Page.
  2. Click Sign In.

 

 

 

Do Not Remain Signed In

 

  1. If presented with this screen, Click No.

 

 

Azure Management Console

 

The Azure management console page will appear.

 

 

Click Virtual Machines

 

  1. Click Virtual Machines.

 

 

Click Web VM

 

  1. Click abCart-Web01-Azure.

 

 

Click on Tags on left column. Add tags to existing Web server

 

 

 

 

Enter the Tag Information

 

  1. Type nsx.network for Name. (Note: in Azure it is a period vs a colon)
  2. Type default for Value.
  3. Click Save.

Tagging of this vm with nsx.network tag will notify NSX Gateway that this VM is now managed by NSX. Between 1-2 mins NSX Gateway will start the process of installing NSX tool (agent) on this VM. This is because we have Auto Agent Install feature enabled. NSX Tool (agent) install will happen in background and will take approx. 5 mins.

When the NSX Agent installation is complete the VM network interface will be moved to the underlay network security group (NSG).

 

 

Summary

We have applied the NSX-specific Tag to the web frontend. Once the NSX Tool is deployed, this tag will "attach" the virtual machine that was created during the NSX Cloud Gateway deployment. Security policies will also be applied to this virtual machine.

 

Verify Logical Groups in NSX Manager


NSX is able to leverage contextual information about workloads to create dynamic policy groups. This provides a greatly simplified operational model for security policy management. In this lesson we will review the pre-configured groups and then finish several of them to simplify policy management.

CSM is able to sync cloud inventory information to pull in the tags that have been applied to the cloud workloads. Typically, these tags are added during the deployment of instances and virtual machines in AWS and Azure. Some examples of tags might be the application name, application tier, etc. NSX will also import cloud environment information tags such as VPC or VNet name that can also be used.

These Tags, along with tags that have been applied to our on-premises virtual machines, will be used to create dynamic logical groupings in NSX.


 

Open a new browser tab

 

  1. Click the Empty Tab in Google Chrome to open a new browser tab (or switch to the NSX Manager tab in Chrome if it's already open).

 

 

NSX Manager Bookmark

 

  1. Click the NSX Manager bookmark to connect to the NSX Manager console.

 

 

Log in to NSX Manager

 

  1. Type admin for the Username.
  2. Type VMware1!VMware1! for the Password.
  3. Click Log In.

 

 

Click Groups in the Inventory Menu

 

  1. Click Inventory.
  2. Click Groups.

 

 

Review Created Groups

 

Groups for ABCart application have already been created to save time in the lab. We will review these four groups. ABCart, ABCart-Web, ABCart-App, and ABCart-DB.

These will be used in the firewall policies that we will create in Enable Firewall Policies section.

 

 

Review ABCart Group Membership

 

  1. Select ABCart.
  2. Click View Members.

 

 

Check Group Definition

 

  1. Select Group Definition
  2. Select Criteria
  3. Review Criteria for all OnPrem, AWS and Azure.
  4. Click Close

This is showing all machines that are part of ABCart application (Web, App and DB). Notice that we are leveraging the native tags that NSX will discover from the public cloud inventory (dis:<cloud>: prefix on those tags).

We have used tags as membership criteria for all groups.

 

 

Review ABCart-Web membership criteria

 

  1. Select ABCart-Web.
  2. Click View Members

 

  1. Select Group Definition
  2. Review Criteria for both AWS and Azure.
  3. Click Close

 

 

Review ABCart App and DB Virtual Machines Tags

 

  1. Click on Inventory
  2. Click on Virtual Machines

 

 

  1. Click on Tags in front of abcart-app01a to review App-Name and App-Tier
  2. Repeat steps for abcart-db01a

The virtual machines running in our on-premises data center and public cloud have tags already applied. We are using them to in these groups.

 

 

Review ABCart-App membership criteria

 

  1. Click on Inventory.
  2. Click on Groups.

 

  1. Select ABCart-App.
  2. Click View Members

 

  1. Select Group Definition
  2. Review Criteria for OnPrem.
  3. Click Close.

 

 

Review ABCart-DB Group

 

  1. Select ABCart-DB.
  2. Click View Members

 

  1. Select Group Definition
  2. Review Criteria for OnPrem.
  3. Click Close.

 

Enable Firewall Policies in NSX Manager


NSX is able to create security policies that leverage the dynamic nature of our cloud environments. This provides a more streamlined and operationally consistent deployment model for security policies.


 

Switch to the NSX Manager Browser Tab

 

  1. Select the NSX Manager browser tab in Google Chrome that was opened previously. Note: The order of browser tabs may differ if you have completed previous Modules.

 

 

Click Security Tab in NSX-T

 

  1. Click Security.

 

 

Change Browser Zoom

 

  1. Click the Three Dots in the upper right.
  2. Change the Zoom level to 80% to make the rules more readable.

 

 

Review Configured Policies

 

  1. click on Security tab.
  2. Click on Distributed Firewall.
  3. Click on Category Specific Rules.
  4. Click on Application.
  5. Expand ABCart Policy.

 

 

Expand ABCart Policy. The security policies that allow our application to function have been pre-created but disabled to save time. We will walk through a brief review of a few points before enabling.  Please review these policies before moving forward.

 

 

App Isolation

 

  1. Verify Applied To:

Note that the ABCart-app group we finished earlier is being used. This will apply this firewall section to only those virtual machines, giving us a mechanism to isolate this application from the rest of the environment.

 

 

Source Destination Groups

 

The groups we reviewed and completed previously are being used as Source and Destination pairs for our application, making policies more dynamic and easier to maintain.

 

 

Traffic Services

 

Services are pre-configured in NSX, simplifying the selection of the traffic types that are required. We are also using a custom Service for HTTP port 8080.

 

 

Deny All rule

 

The final Deny All rule is set to Drop all other traffic that we aren't explicitly allowing (you will need to scroll down).

 

 

Enable All Rules

 

  1. Click the Three Dots next to ABCart Policy at the top.
  2. Click Enable All Rules.

 

As you can see now all rules are enabled.

 

 

Logging Enabled

 

  1. Click the Three Dots next to ABCart Policy at the top.
  2. Click Enable logging for all rules.

 

  1. Verify logging by clicking on settings gear next to any firewall rule.

 

Logging has been turned on for all the rules, and the logs are being sent to the Log Insight deployment.

 

 

Click Publish to Save the Rules

 

  1. Scroll back up and click Publish on top right to save the rules.

The security policies for the application has been enabled.

 

Test Hybrid Cloud Application


Prior to NSX deployment, the application running in Amazon Web Services and Microsoft Azure was left wide open to the Internet and several unneeded ports were exposed as potential attack surfaces. This lesson will revisit the application functionality and test basic connectivity.


 

Accessing Account Information (AWS)

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the Account Info bookmark.

 

 

Locate the AWS Web Instance Information

 

  1. Click on the Web Frontend Public URL link to open a new browser tab and connect to the application.

 

 

Verify Application is Functioning

 

Verify that the application is functioning. The web front end is working, and we can further test the rest of the application components:

 

  1. Click Apparel & Accessories.

All application components are properly communicating between AWS and our on-premises data center.

 

 

Accessing Account Information

 

  1. Click on the Account Information tab that was previously opened. If this tab was closed open another tab and click on the Account Info bookmark.

 

 

Locate the Azure Web VM Information (Azure)

 

  1. Click on the Web Frontend Instance Public URL link to open a new browser tab and connect to the application

 

 

Verify Application is Functioning

 

Verify that the application is functioning. The web front end is working, and we can further test the rest of the application components.

 

  1. Click on Makeup.

All application components are properly communicating between Azure and our on-premises data center.

 

Test NSX Security Firewall Enforcement


In this section we will explore how we can provide security enforcement. NSX provides these capabilities via Distributed Firewall in hypervisor for on-prem workloads (App and DB) and NSX Tools running in Web workloads in public cloud (AWS and Azure).


 

Log into NSX Manager

 

  1. Click on VMware NSX
  2. Username: admin
  3. Password: VMware1!VMware1!
  4. Click LOG IN

 

 

Review NSX Firewall Rules

 

  1. Click Security.
  2. Click Distributed Firewall.

In the interest of time we have already configured rules.  We will now review these rules now. We are also using groups we created in earlier section.

 

  • Internet to Web: Allow HTTP access to ABcart-Web VM from outside.
  • Web to App: ABcartWeb VM will talk to ABcart App VM on TCP_8080.
  • App to DB: ABcart App VM will talk to ABcart DB VM on MySQL.
  • Deny All: Deny all other communications.

 

 

Firewall Rules Enforcement

We will go ahead and drop Internet to Web in ABCart Policy. This will break hybrid application.

 

  1. For Internet to Web click on Action Drop down.
  2. Select Reject.
  3. Click Publish.

 

 

Test ABCart Application

 

Click on ABCart URL from Hands on Lab Page.

 

Note - this may take a few minutes to return.

As you can see we are not able to connect to web server in AWS . This shows that our rules are getting enforced on web VM running in AWS.

 

Traffic Visibility


NSX provides additional operational tools for application traffic visibility. This includes applications running in public clouds. We will look at the network topology and some of the traffic statistic aggregation features of NSX.


 

Switch to the NSX Manager Browser Tab

 

  1. Select the NSX Manager browser tab in Google Chrome that was opened previously. Note: The order of browser tabs may differ if you have completed previous Modules. Enter admin for the username and VMware1!VMware1! for the password if it has timed out.

 

 

Change Browser Zoom

 

  1. Click the Three Dots in the upper right.
  2. Change the Zoom level to 80% to make the next steps more readable.

 

 

Network Topology

 

1. Click Networking

2. Click on Network Topology

3. Minimize the overview dialog

This shows all the network with T0s, T1s, Segments and all connects VMs

 

1. Expand all VMs by clicking on VMs

2. Click on the first Router.

3. You will notice it is a T1 VPC router for AWS. For each VPC/VNET we deploy a T1 Router.

 

1. Click on the top router you will find it is a T0 VPC for AWS. For each VPC/VNET we deploy a T0. For Linked VPCs/VNETs we don't deploy another T0.

 

1. Click on one of the VMs

2. You will find it is the OpenMRS-Web01-AWS

Do the same for other T0s, T1s, segments and VMs to understand the topology.

 

 

Click Security

 

  1. Click Security on top.
  2. Click Distributed Firewall..

 

 

Firewall Statistics

 

  1. Click the Flow Statistics icon on the far right of the first firewall rule.

 

 

Flow Statistics

 

The packets, bytes and number of sessions for this rule are displayed.

 

 

Check ABcart-PG Traffic Statistics

 

1. Click Networking

2. Click Segments on the left.

 

  1. Expand ABcart-PG.
  2. Click on View Statistics to review then close that window.

 

 

You see all received and transmitted traffic on the segment.

 

 

Check ABcart-PG Connected Ports

 

  1. Click Ports.

 

You will see two ports already connected (App01 and DB01)

 

Conclusion


This completes Module 4 and the Hands-On Lab. The eCommerce ABCart application that was deployed in our hybrid cloud environment has been successfully connected via VPN and secured by installing NSX components in Amazon Web Services and Microsoft Azure and applying consistent security policies to the application instances.

  • Deployed Public Cloud Gateway on Transit VPC and VNet of Public Clouds
  • Deployed NSX VPN for both Public Clouds (AWS and Azure)
  • Configured BGP and Forwarding policies in NSX Manager
  • Deployed and verified NSX Tools (agent) in EC2 instance and Azure VM
  • Applied native tags to EC2 instance and Azure VM
  • Enabled NSX firewall rules (DFW) in NSX Manager
  • Verified NSX firewall enforcement in EC2 instance and Azure VM

 

Congratulations, you've finished Module 4 and the Hands-On Lab!

Follow the instructions at the end of this lesson to end the lab. You may also proceed to any module of interest.

  • Module 1 - Introduction to Public Cloud Environments  (30 minutes) Basic - In this module we will log in to the AWS and  Azure consoles to view the inventory of resources that have been  created. We will also review the configured application environment, verify application functionality, and review configured security  policies and posture.
  • Module 2 - Introduction to NSX Management Components  (15 minutes) Basic - In this module we will log in to On-premises  components like vCenter, NSX Manager and NSX Cloud Service Manager  (CSM) and explore the NSX Manager and NSX Cloud Services Manager capabilities and configuration.
  • Module 3 - Securing Native Cloud Applications with NSX  (60 minutes) Basic - In this module we will deploy and validate the  installation of NSX Public Cloud Gateway (PCG) in the AWS and Azure environments and secure the healthcare application OpenMRS with native security enforcement feature (agent-less).

Advance Module - Deploying NSX VPN to establish connectivity between On-Prem and Public Clouds:

  • Module 4 - Securing Hybrid Cloud Applications with NSX  (60 minutes) Advanced - In this module we will deploy and validate the  installation of NSX VPN between On-Prem and Public Clouds AWS & Azure and secure hybrid eCommerce applications ABCart running in On-premises, AWS and Azure with NSX security enforcement feature (agent).

 

 

How to End Lab

 

To end your lab click on the END button.

 

Conclusion

Thank you for participating in the VMware Hands-on Labs. Be sure to visit http://hol.vmware.com/ to continue your lab experience online.

Lab SKU: HOL-2122-01-NET

Version: 20201019-165714