Using NSX CloudVMware NSX Cloud

Using NSX Cloud

VMware, Inc. 2

You can find the most up-to-date technical documentation on the VMware website at:

https://docs.vmware.com/

If you have comments about this documentation, submit your feedback to

docfeedback@vmware.com

Copyright © 2018 VMware, Inc. All rights reserved. Copyright and trademark information.

VMware, Inc.3401 Hillview Ave.Palo Alto, CA 94304www.vmware.com

Contents

1 Using NSX Cloud 5

2 Add your Public Cloud Inventory 6

Add AWS Account 6

Configure your AWS Compute VPC 8

Deploy the Public Cloud Gateway 9

Behind the Scenes: after adding AWS account and deploying PCG 10

3 Prepare your VMs for NSX 13

Considerations for NSX-managed VMs 13

Non-overlay (underlay) and Overlay VMs 14

Install NSX agent 15

Apply the nsx:network tag to VMs in AWS 17

(Optional) Generate AMI 17

Behind the Scenes: after you prepare your VMs for NSX 19

4 Accessing NSX-managed VMs 20

Access Non-overlay (Underlay) VM 20

Access Overlay VM 21

5 Set up Micro-segmentation for Workload VMs 22

6 Set Up the NSX Overlay Network 23

Attach a DHCP server to the Overlay Logical Switch 23

Associate the Tier-0 Router with the Overlay Logical Switch 23

7 Manage Quarantine Policy 25

8 Using Advanced NSX Cloud Features 28

Enable Syslog Forwarding 28

Access AWS Services in the Underlay Network 29

Enable NAT on NSX-managed VMs 30

9 Cheat Sheets and Troubleshooting 32

Onboarding Workflows 32

Verify NSX Cloud Components 34

AWS Tags for NSX Cloud 34

NSX Agent Install Script Options and Uninstallation 35

VMware, Inc. 3

Undeploying PCG 36

Troubleshooting FAQ 37

10 Using the Cloud Service Manager 39

11 Using NSX Manager 40

Using NSX Cloud

VMware, Inc. 4

Using NSX Cloud 1NSX Cloud enables you to manage and secure your cloud inventory using NSX.

VMware, Inc. 5

Add your Public CloudInventory 2Your AWS account contains one or more compute VPCs that you want to manage using NSX. To bringyour inventory into NSX Cloud, you need to start by adding your AWS account in CSM.

This is a three-step process:

n Step 1 (In NSX Cloud): Add your AWS account using the ARN information generated by the JSONtemplate provided by NSX Cloud.

n Step 2 (In your AWS account): Create or select a VPC in the selected deployment region, withspecific configurations.

n Step 3 (In NSX Cloud): Deploy the NSX Public Cloud Gateway (PCG) in the VPC configured forNSX Cloud.

1 Add AWS Account

Add your AWS account using the ARN information generated by the JSON template provided byNSX Cloud.

2 Configure your AWS Compute VPC

Your AWS compute VPC needs specific configurations for NSX Cloud.

3 Deploy the Public Cloud Gateway

Deploy the NSX Public Cloud Gateway (PCG) on the AWS compute VPC.

4 Behind the Scenes: after adding AWS account and deploying PCG

Essential NSX entities are created and configured in your AWS account and in NSX Manager afterthe three-step process of enabling CSM to access your AWS inventory.

Add AWS AccountAdd your AWS account using the ARN information generated by the JSON template provided byNSX Cloud.

VMware, Inc. 6

Procedure

1 In NSX Cloud: From the NSX Cloud dashboard, copy the JSON template URL from the Resources

tile.

2 Switch to your AWS account to do the following:

a Create a new Stack in the CloudFormation service.

b Select the checkbox on the Review screen acknowledging that AWS might create IAM resourceswith custom names.

c Click Create. The NSX Cloud JSON template creates three identifiers that are needed to add this

account in CSM. This process takes some time to finish.

d Click on the Outputs tab when the creation process completes.

e Make a note of the values for IAMRoleARN, ExternalID, and GatewayRoleName.

Note You have the option to use your AWS account’s Access Key and Secret Key for adding it intoCSM, but it is not recommended because of security concerns.

Using NSX Cloud

VMware, Inc. 7

3 Switch to CSM to do the following:

a Click Cross-Cloud > Accounts > (+) Add AWS Account.

b Enter the following details on this screen:

Option Description

Account Name Provide a descriptive name for this AWS VPC

IAM Role ARN Use the value generated from the AWS Stack

External ID Use the value generated from the AWS Stack

Gateway Role Name Use the value generated from the AWS Stack

c Click Save.

The AWS account gets added in CSM.

In the VPCs tab of CSM, you can view all the VPCs in your AWS account.

In the Instances tab of CSM, you can view the EC2 Instances in this VPC.

What to do next

Configure your AWS Compute VPC

Configure your AWS Compute VPCYour AWS compute VPC needs specific configurations for NSX Cloud.

You can use the CloudFormation template linked from the NSX Cloud Dashboard's Resources tile, tocreate a compute VPC with all the basic settings required for NSX Cloud. The CloudFormation templatecreates the following:

n six subnets for supporting PCG with High Availability

n an Internet gateway (IGW)

n a private and a public route table

n subnet association with route tables

n DNS resolution and DNS hostnames enabled.

The following steps provide information on these configurations and how you can set them yourself inAWS.

Using NSX Cloud

VMware, Inc. 8

Procedure

1 Assuming your VPC uses a /16 network, for each gateway that needs to be deployed, set up threesubnets.

Important If using High Availability, set up three additional subnets in a different Availability Zone.

n Management subnet: This subnet is used for NSX management of CGW. The recommendedrange is /24.

n Uplink subnet: This subnet is used for North-South internet traffic. The recommended rangeis /24.

n Downlink subnet: This subnet encompasses the workload VM's IP address range, and should besized accordingly. Bear in mind that you may need to incorporate additional interfaces on theworkload VMs for debugging purposes.

Note Label the subnets appropriately, for example, management-subnet, uplink-subnet,downlink-subnet,because you will need to select the subnets when deploying PCG on this VPC.

2 Ensure you have an Internet gateway (IGW) that is attached to this VPC.

3 Ensure the routing table for the VPC has the Destination set to 0.0.0.0/0 and the Target is theIGW attached to the VPC.

4 Ensure you have DNS resolution and DNS hostnames enabled for this VPC.

What to do next

Deploy the Public Cloud Gateway

Deploy the Public Cloud GatewayDeploy the NSX Public Cloud Gateway (PCG) on the AWS compute VPC.

When you deploy PCG, you are able to establish North-South connection. AWS Security Groups arecreated as part of the process of deploying PCG. See Chapter 7 Manage Quarantine Policy for moreinformation.

Note It is recommended that your AWS IAM policies include deny statements preventing users frommodifying gateway resources to PCG.

Procedure

1 From the CSM dashboard, select Cross-Cloud > AWS > <AWS_account_name>

2 Select an AWS region name, for example, us-west. The AWS region must be the same where youcreated the compute VPC.

3 From the VPC section, select the compute VPC configured for NSX Cloud.

4 Click Deploy Gateways.

Using NSX Cloud

VMware, Inc. 9

5 Complete the general gateway details:

Option Description

PEM File Select one of your PEM files from the drop-down menu. This file must be in thesame region where NSX Cloud was deployed and where you created yourcompute VPC.

This uniquely identifies your AWS account.

Quarantine Policy on the AssociatedVPC

The default selection is Enabled. This is recommended for greenfielddeployments. If you already have VMs launched in your VPC, disable theQuarantine policy. See Chapter 7 Manage Quarantine Policy

6 Click Next.

7 Complete the High Availability gateway details.

Option Description

Enable HA for Public Cloud Gateway The recommended setting is Enable, that sets up a High AvailabilityActive/Standby pair to avoid an unscheduled downtime.

Primary gateway settings Select an Availability Zone such as us-west-1a, from the drop-down menu as theprimary gateway for HA.

Assign the uplink, downlink, and management subnets from the drop-down menu.

Secondary gateway settings Select another Availability Zone such as us-west-1b, from the drop-down menu asthe secondary gateway for HA.

The secondary gateway is used when the primary gateway fails.

Assign the uplink, downlink, and management subnets from the drop-down menu. Click Deploy.

8 Monitor the status of the primary (and secondary, if you selected it) PCG deployment. This processcan take 10-12 minutes.

9 Click Finish when PCG is successfully deployed.

Click the Gateways link on the VPC. the primary and secondary gateway names appear. The status of thecompute VPC appears as NSX Managed.

See Undeploying PCG for instructions and prerequisites for undeploying a PCG.

Behind the Scenes: after adding AWS account anddeploying PCGEssential NSX entities are created and configured in your AWS account and in NSX Manager after thethree-step process of enabling CSM to access your AWS inventory.

NSX Manager ConfigurationsThe following entities are automatically created in NSX Manager:

n An Edge Node named Public Cloud Gateway (PCG) is created.

Using NSX Cloud

VMware, Inc. 10

n The PCG is added to Edge Cluster.

n The PCG is registered as a Transport Node with two Transport Zones created.

n Two default logical switches are created.

n One tier-0 logical router is created.

n An IP Discovery Profile is created. This is used for overlay logical switches.

n A DHCP Profile is created. This is used for DHCP servers.

n A default NSGroup with the name PublicCloudSecurityGroup is created that has the followingmembers:

n The default VLAN logical switch

n Logical ports, one each for the PCG uplink ports, if you have HA enabled.

n IP address

n Three default distributed firewall rules are created:

n LogicalSwitchToLogicalSwitch

n LogicalSwitchToAnywhere

n AnywhereToLogicalSwitch

Verify these configurations in NSX Manager:

1 From the NSX Cloud dashboard, click NSX Manager.

2 Browse to Fabric > Nodes > Edge. Public Cloud Gateway should be listed as an Edge Node.

3 Verify that Deployment Status, Manager Connection and Controller Connection are connected (statusshows Up with a green dot).

4 Browse to Fabric > Nodes > Edge Clusters to verify that the Edge Cluster and PCG were added aspart of this cluster.

5 Browse to Fabric > Nodes > Transport Nodes to verify that PCG is registered as a Transport Nodeand is connected to two Transport Zones that were auto-created while deploying PCG:

n Traffic type VLAN -- this connects to the PCG uplink

n Traffic type Overlay -- this is for overlay logical networking

6 Verify whether the logical switches and the tier-0 logical router have been created and the logicalrouter added to the Edge Cluster.

Important Do not delete any of the NSX-created entities. See Chapter 6 Set Up the NSX OverlayNetwork to complete the manual configurations required for the overlay network.

Using NSX Cloud

VMware, Inc. 11

AWS ConfigurationsIn the AWS compute VPC, the following is configured after PCG is deployed:

n A set of security groups are created in AWS that allow NSX Cloud to apply the Quarantine policywhen it is enabled for a VPC.

n The gw security groups are applied to the respective PCG interfaces.

Table 2‑1. AWS Security Groups created by NSX Cloud for CGW Interfaces

AWS Security Group name Full Name

gw-mgmt-sg Gateway Management Security Group

gw-uplink-sg Gateway Uplink Security Group

gw-vtep-sg Gateway Downlink Security Group

n The vm security groups are applied to workload VMs. If the Quarantine Policy is enabled, thesecurity group assignment for all interfaces for any VMs belonging to this VPC is managed byNSX Cloud.

Table 2‑2. AWS Security Groups created by NSX Cloud for Workload VMs

AWS Security Group name Full Name

default Default Security Group

vm-underlay-sg VM Non-Overlay Security Group

vm-overlay-sg VM Overlay Security Group

vm-override-sg VM Override Security Group

vm-outbound-bypass-sg VM Outbound Bypass Security Group

vm-inbound-bypass-sg VM Inbound Bypass Security Group

Note NSX Cloud provides the minimum required access for using NSX. To allow any otheraccess beyond that, add a custom SG in addition to the appropriate SG assigned by NSX Cloud.

See Chapter 7 Manage Quarantine Policy for more details.

n In the AWS VPC, a new Type A Record Set is added with the name nsx-gw.vmware.local. The IPaddress mapped to this record matches the Management IP address of PCG. This is assigned byAWS using DHCP and will differ for each VPC.

n A secondary IP for the uplink interface for PCG is created. An AWS Elastic IP is associated with thissecondary IP address. This configuration is for SNAT.

Using NSX Cloud

VMware, Inc. 12

Prepare your VMs for NSX 3This is a two-step process.

1 Install the NSX Agent on your Windows or Linux VM. See Install NSX agent.

2 Tag the VM in AWS for NSX Cloud. See Apply the nsx:network tag to VMs in AWS.

Currently, the following operating systems are supported:

n Ubuntu 14.04, 16.04

n Oracle Enterprise Linux 7.2, 7.3, 7.4

n Red Hat Enterprise Linux (RHEL) 7.2, 7.3, 7.4

n CentOS 7.2, 7.3, 7.4

n Windows Server 2012 R2

This chapter includes the following topics:

n Considerations for NSX-managed VMs

n Non-overlay (underlay) and Overlay VMs

n Install NSX agent

n Apply the nsx:network tag to VMs in AWS

n (Optional) Generate AMI

n Behind the Scenes: after you prepare your VMs for NSX

Considerations for NSX-managed VMsThere are some requirements and recommendations to enable the management of workload VMs usingNSX.

Requirements and Recommendationsn Make sure your workload VM is connected to the same network as the downlink subnet of the PCG.

VMware, Inc. 13

n If you have the Quarantine Policy enabled for your compute VPC, before installing the NSX agent,assign the vm-override-sg security group to the VM to ensure it is not quarantined. WhenQuarntine Policy is enabled, VMs that do not have the NSX agent installed on them are automaticallyassigned the default security group and thereby quarantined. See Chapter 7 Manage QuarantinePolicy for more information.

n If you have Quarantine Policy disabled, NSX Cloud does not apply any security groups to VMs. Afterinstalling the agent and tagging the VM as either underlay or overlay, assign the appropriate securitygroup to the VM. See Chapter 7 Manage Quarantine Policy for more information.

Note For Brownfield deployments, it is recommended to have the Quarantine Policy disabled. Thisis to prevent your existing workload VMs from being quarantined by NSX Cloud.

n Workload VM communication with PCG is permitted for essential protocols. For uncommon usecases, for example the use of DNS-UDP, you need to create a DFW permit rule. See Add FirewallRule in the NSX-T Administration Guide.

Non-overlay (underlay) and Overlay VMsYour workload VMs can be either in the underlay or overlay mode.

About Underlay VMsAn underlay VM utilizes the underlying public cloud networking and does not make use of NSX virtualnetwork overlays. The characteristics for an underlay VM are:

n Requires the nsx:network tag key with the value default.

n Is assigned the vm-underlay-sg security group in AWS.

n Is assigned an IP address from the AWS underlay network.

n Is set up to use the DNS server assigned to the compute VPC in AWS where this VM is launched.

n Workload VMs in underlay mode can be accessed once the distributed firewall (DFW) configuration isset on NSX Manager. See Access Non-overlay (Underlay) VM for details.

About Overlay VMsAn overlay VM utilizes an overlay network and allows the use of additional NSX features. Thecharacteristics for an overlay VM are:

n Requires the nsx:network tag key with the value of the logical switch UUID assigned to this VM.

n Is assigned the vm-overlay-sg security group in AWS.

Using NSX Cloud

VMware, Inc. 14

n Is assigned its IP address and the DNS server IP address from the NSX overlay network via the NSXDHCP server attached to the logical switch that this VM is associated with.

Note A workload VM in overlay mode is accessible from other VMs also in the overlay network. It isrecommended to create a single jumphost overlay VM with appropriate firewall rules for externalaccess. Access to all overlay workload VMs can then be accomplished from this jumphost. See Access Overlay VM for details.

Install NSX agentInstall the NSX Agent on your workload VMs

This is the first of two steps required to enable NSX to manage your workload VMs.

Install the NSX Agent on your Windows VMsFollow these instructions to install the NSX agent on your Windows workload VM.

Procedure

1 Find the VM’s public or private IP address so you can connect to it using RDP:

Note: If using a jumphost, you do not need the public IP address, you can use the private IP address.This is the recommended method of accessing your workload VMs.

2 Download the installation script:

a Open a PowerShell prompt, and run the following command to get the IP address of the PCG:Resolve-DnsName nsx-gw.vmware.local -Server 169.254.169.253

Note: The default DNS name of PCG is nsx-gw.vmware.local. AWS Route 53 maps this namewith the primary PCG IP address. The secondary PCG’s IP address, if you have one for HA, isalso mapped to the same DNS name.

b Download the installation script fromhttp://<IP address returned by Resolve-DnsName>:

8080/factory_default/win63_x64/nsx_install.ps1

3 Run the NSX agent installationscript: \nsx_install.ps1 -downloadPath <path> -operation install

The script uses the interface with the lowest index as the default interface. For a list of all scriptoptions and uninstallation instructions, see NSX Agent Install Script Options for Windows VMs.

What to do next

Apply the nsx:network tag to VMs in AWS

Install the NSX Agent on your Linux VMsFollow these instructions to install the NSX agent on your Linux workload VM.

Using NSX Cloud

VMware, Inc. 15

Prerequisites

See Chapter 3 Prepare your VMs for NSX for a list of Linux distributions currently supported.

Important NSX Agent installation on Linux VMs requires internet access for downloading dependencieswhile installing NSX packages. To ensure this is possible:

n Make sure your Linux workload VM has a public IP address or assigned a NAT gateway.

n If NSX Cloud's Quarantine Policy is enabled, apply the vm-override-sg security group to the VM toensure it is not quarantined.

Procedure

1 Note the workload VM's IP address from AWS or CSM.

2 Log in to the workload VM using SSH.

3 Copy the following bash script and run it in the workload VM. This resolves the domain name for thePCG and downloads the installation script for your specific OS.

#Determining the NSX agent installation path from the workload VM's OS type

_os=`grep -Po '^ID=\K.*' /etc/os-release | sed -e 's/^"//' -e 's/"$//'`;

case "$_os" in

ubuntu)

_platform="$(/usr/bin/lsb_release -cs)_amd64";;

rhel|ol|centos)

_platform="${_os}$(grep -Po "[0-9]*\.[0-9]*" /etc/redhat-release | head -n1 | tr -d

'.')_x86_64";;

*)

_platform=''; echo "Unsupported OS";;

esac;

#Resolving the PCG hostname from the public cloud DNS server

if [ ! -z "$_platform" ]; then

ipaddrs=`nslookup nsx-gw.vmware.local 169.254.169.253 | awk '/^Address: / { print $2 }'`;

for gwip in $ipaddrs;

do

wget -T 5 -t 1 http://$gwip:8080/factory_default/$_platform/install_nsx_vm_agent.sh && break ;

done;

fi

Note: You need the wget and nslookup commands to run this script.

4 Change permissions on the installation script to make it executable, and run it:

a sudo chmod +x install_nsx_vm_agent.sh

b sudo ./install_nsx_vm_agent.sh

The script uses eth0 as the default interface. For a list of script options, and uninstallationinstructions, see NSX Agent Install Script Options for Linux VMs.

Note: After the NSX agent is successfully installed, port 8888 shows as open on the VM but it is onlymeant for advanced troubleshooting for NSX Cloud.

Using NSX Cloud

VMware, Inc. 16

What to do next

Apply the nsx:network tag to VMs in AWS

Apply the nsx:network tag to VMs in AWSTag VMs with the NSX agent installed on them as either overlay or non-overlay (underlay) in AWS. This isthe final step in the two-step process to enable NSX to manage VMs.

You can apply the AWS tag either at the VM-level or the interface-level, but once you decide where toapply the tag, you must use the same level to apply the other tags. For example, if you tagged theinterface with the nsx:network tag, you cannot apply other tags for this VM in AWS at the VM-level, youmust choose the interface for any other tag.

The AWS tag’s key is nsx:network.

For VMs in underlay mode, type in default (case-sensitive) for the tag value.

For VMs in overlay mode, do the following to find the tag value information:

1 From the CSM dashboard, select Cross-Cloud > AWS > <AWS_account_name>

2 From the VPC section, select <your-compute-VPC> > Logical Switches

3 Double-click and copy the value in the column NSX Switch Tag.

Procedure

1 Log in to the AWS console.

2 In the AWS console, select the VM with the NSX agent installed.

3 Add the tag details for the VM and save your changes.

Option Description

Key Enter nsx:network

Value For underlay VMs: Type in default (case-sensitive).

For overlay VMs: Paste the NSX logical switch tag ID you copied from CSM.

Example logical switch UUID:c26b5f59-1648-462e-b747-287c72e82a87#OOUeB/I1M+v

+zOXFoE4e5+UxCTmlsZpD4z7AQIhiFoG=

Important If you have the Quarantine Policy enabled, and you assigned the vm-override-sgsecurity group to this VM to prevent it from being quarantined while your prepare it for NSX, removethe vm-override-sg security group after applying the tag. NSX Cloud automatically assigns the vm-overlay-sg or vm-underlay-sg to the VM depending on the tag you applied.

(Optional) Generate AMIYou can generate an AMI of a VM with the NSX agent installed on it.

Using NSX Cloud

VMware, Inc. 17

You can install the NSX agent in an unconfigured, stopped state, on a workload VM and generate an AMIout of it from the AWS console. This helps in eliminating the effort of installing the NSX agent on eachworkload VM separately.

Subsequently, VMs can be created from that AMI with the pre-installed NSX agent, but this time the agentgets configured and runs.

You need to tag each of these workload VMs in AWS to complete their NSX-onboarding. See Apply thensx:network tag to VMs in AWS for the next step.

There are two ways in which you can generate an AMI of a VM with the NSX agent installed on it:

n Generate AMI with an unconfigured NSX agent: You can generate an AMI from a VM that has theNSX agent installed on it but not configured by using the -noStart option. This option allows theNSX agent package to be fetched and installed but the NSX services are not started. Also, no NSXconfigurations such as certificate generation, are made.

n Generate AMI after removing existing NSX agent configurations: You can remove configurationsfrom an existing NSX-managed VM and use it for generating AMIs.

Generating AMI with an unconfigured NSX agentYou can generate an AMI of a VM with the NSX agent installed on it and not configured.

To generate AMIs from a VM that has the NSX agent installed on it using the -noStart option, do thefollowing:

Procedure

1 Install the NSX agent:

a Enter the following command on a Windows VM:

.\nsx_install.ps1 –noStart true

b Enter the following command on a Linux VM:

sudo

./install_nsx_vm_agent.sh –-no-start

2 Go to this VM in AWS and create an AMI.

What to do next

Apply the nsx:network tag to VMs in AWS

Generating AMI after removing existing NSX agent configurationsYou can generate an AMI of a VM that has a configured NSX agent.

Using NSX Cloud

VMware, Inc. 18

To remove configurations from an existing NSX-managed VM and use it for generating AMIs, do thefollowing:

Procedure

1 Removing NSX agent configurations from a Windows or Linux VM:

a Open the NSX-T CLI:

sudo nsxcli

b Enter the following commands:

hostname> set debug

hostname> clear nsx-vm-agent state

2 Locate this VM in the AWS console and create an AMI.

What to do next

Apply the nsx:network tag to VMs in AWS

Behind the Scenes: after you prepare your VMs for NSXEssential NSX-T entities are created and configured automatically after you prepare your VMs for NSX.

The following is the list of these configurations:

n A logical port is created for this VM.

n The VM is marked as NSX managed.

n The VM is reported as part of the inventory in NSX Manager to achieve, for example, micro-segmentation on logical constructs.

n East-West traffic is enabled for this VM.

Using NSX Cloud

VMware, Inc. 19

Accessing NSX-managed VMs 4After you have workload VMs set up to be managed by NSX, follow workflows recommended for VMs inthe underlay or VMs in the overlay mode to access them.

NSX-managed workload VMs need specific access workflows. AWS security groups for NSX-managedVMs and distributed firewall rules in NSX Manager limit access to workload VMs and need to beconfigured depending on your security requirements and use cases.

Note An alternative way to access Windows workload VMs in the overlay or underlay mode is by using ajumphost in the AWS underlay network. This jumphost does not need to be NSX-managed. Apply thevm-override-sg to the jumphost VM if the Quarantine Policy is enabled.

This chapter includes the following topics:

n Access Non-overlay (Underlay) VM

n Access Overlay VM

Access Non-overlay (Underlay) VMFollow this workflow to access NSX-managed VMs in the underlay mode.

At the time of deploying the PCG on your compute VPC, NSX Cloud creates default firewall rules toenhance the security of your workload VMs. See NSX Manager Configurations.

To access NSX-managed workload VMs in underlay mode you need to add a distributed firewall (DFW)rule that opens up access to the VM.

Do the following:

1 From the NSX Cloud Dashboard, click NSX Manager to open the NSX Manager console in thecurrent browser window.

2 Go to Firewall > General > Add Rule

3 Add a rule with the following configurations. See Add a Firewall Rule in the NSX-T AdministrationGuide for detailed instructions.

n Name: Provide a name to define the purpose of this rule, for example,AllowRemoteAccessToUnderlay

n Source: Pick Any

VMware, Inc. 20

n Destination: Pick the logical switch or port or NSGroup that is VM is attached to or is a memberof.

n Services: Pick remote-access services for this workload VM, for example, SSH for Linux, or RDPfor Windows.

n Action: Pick Allow

Note This rule must be placed before the default reject-rule AnywhereToLogicalSwitch (rejectseverything from Any source to the default PublicCloudSecurityGroup. See Behind the Scenes: afteradding AWS account and deploying PCG for more information.

Access Overlay VMAccess to VMs in the overlay mode is recommended via a jumphost.

Configure the jumphost VM to be NSX-managed in the overlaymode1 In AWS: Launch a jumphost VM each for the Windows and Linux operating systems.

2 In AWS: Apply the vm-override-sg security group to the jumphost VM.

3 Download and install the NSX agent on the jumphost VM. See Install NSX agent for instructions.

4 In AWS: Tag the jumphost VM with the key nsx:network and value<UUID of the logical switch this jumphost VM is attached to>

Note Do not remove the vm-override-sg security group from the jumphost VM. See Chapter 7Manage Quarantine Policy for details on security groups and the Quarantine Policy.

Ensure the jumphost VM is connected to the NSX overlay networkand has Internet access1 In NSX Manager, confirm that:

n the jumphost VM is connected to an overlay logical switch

n the overlay logical switch is connected to the Tier-0 router

n a DHCP server with the profile PublicCloudDhcpProfile-<vpc-name> is attached to the overlaylogical switch

2 In NSX Manager, add a firewall rule to allow access to the jumphost via SSH or RDP. See Add aFirewall Rule for instructions.

3 In AWS, add the NSX Cloud tag that enables NAT for the jumphost VM. The tag's key isnsx:publicip and its value is <EIP from AWS>. See Enable NAT on NSX-managed VMs for details.

Using NSX Cloud

VMware, Inc. 21

Set up Micro-segmentation forWorkload VMs 5Apply distributed firewall rules to NSX-managed VMs.

Once you have prepared your workload VMs to be managed by NSX, you can set up micro-segmentationfor these VMs.

1 Create NSGroups using VM names or tags or other membership criteria, for example, for web, app,DB tiers. For instructions, see Create an NSGroup in the NSX-T Administration Guide.

Note You can use any of the following tags for membership criteria. See Using tags in NSX fororganizing your workload VMs for details.n system-defined tags, that are aws:vpc or aws:availabilityzone

n tags from your EC2 environment that are discovered by NSX Cloud

n or your own custom tags

2 Create a firewall rule section and apply to NSGroups, if required. See Add a Firewall Rule Section inthe NSX-T Administration Guide.

3 Create firewall rules and use NSGroups for source and destination as required by your securitypolicy. See Add a Firewall Rule in the NSX-T Administration Guide.

This micro-segmentation takes effect when the inventory is either manually resynched from CSM, orwithin 90 minutes when the changes are polled between AWS and NSX Cloud and implemented.

VMware, Inc. 22

Set Up the NSX OverlayNetwork 6This chapter includes the following topics:

n Attach a DHCP server to the Overlay Logical Switch

n Associate the Tier-0 Router with the Overlay Logical Switch

Attach a DHCP server to the Overlay Logical SwitchYou must attach a DHCP server to the overlay logical switch before the DHCP server can process DHCPrequests from VMs connected to the switch.

Note Use the auto-created DHCP profile for the DHCP server. The profile name isPublicCloudDhcpProfile-<compute-vpc-name>

Procedure

1 From the NSX Cloud dashboard, click NSX Manager.

NSX Manager opens in the current browser window.

2 Select Switching > Switches from the navigation panel.

3 Click the overlay logical switch created by NSX Cloud.

4 Click Actions > Attach DHCP Server.

Example: ReferenceSee Attach a DHCP Server to a Logical Switch in the NSX-T Administration Guide.

Associate the Tier-0 Router with the Overlay LogicalSwitchA tier-0 router and two logical switches are created by NSX Cloud after you deploy PCG. You need toconnect the tier-0 router with the overlay logical switch from the NSX Manager.

VMware, Inc. 23

Procedure

1 From the NSX Cloud dashboard, click NSX Manager.

NSX Manager opens in the current browser window.

2 Select Routing from the navigation panel.

3 Select the tier-0 router.

4 From the Configuration tab, add a new logical router port.

5 Type a name for the port, such as downlink.

6 Select the Downlink type.

7 Select the overlay logical switch with a name like DefaultSwitch-Overlay-<vpc-name>.

8 Select the IP address of the Default Gateway of the DHCP server attached to this logical switch.

A new downlink port is added for the tier-0 router.

Example: ReferenceSee Connect a Tier-0 Logical Router to a VLAN Logical Switch in the NSX-T Administration Guide.

Using NSX Cloud

VMware, Inc. 24

Manage Quarantine Policy 7NSX Cloud uses AWS Security Groups (SG) in conjunction with the VPC’s Quarantine Policy for threatdetection by quarantining rogue VMs.

For example, if a person with malicious intent forcibly stops the NSX agent on a managed VM, thecompromised VM will be quarantined using the default SG in AWS. This is only possible for VPCs thathave the Quarantine Policy enabled.

You can enable or disable Quarantine Policy for a VPC by right-clicking the VPC and selecting EditQuarantine.

Quarantine Policy EnabledWhen Quarantine Policy is enabled:

n The SG assignment for all interfaces for any EC2 Workload Instance (VMs) belonging to this VPC ismanaged by NSX Cloud. Appropriate Workload VM Security Group(s) are assigned to suchinterfaces.n Un-managed VMs are assigned the default SG and are quarantined. This limits the outbound

traffic and stops all inbound traffic to such VMs.

n Un-managed VMs can become NSX-Managed VMs when you install the NSX agent on the VMand tag them in AWS with nsx:network. In the default scenario, NSX will assign the vm-overlay-sg or vm-underlay-sg to allow appropriate inbound/outbound traffic.

n An NSX-Managed VM can still be assigned the default SG and be quarantined if a threat isdetected on the VM, for example, if the NSX agent is stopped on the VM.

n Any manual changes to the security groups will be reverted to the NSX-determined securitygroup(s) within 120 seconds.

VMware, Inc. 25

n If you want to move any VM out of quarantine, that is, move it out of the default SG, assign thevm-override-sg as the only SG to the VM. NSX Cloud does not auto-change the vm-override-sg SG and allows SSH and RDP access to the VM. Removing the vm-override-sgwill again cause the VM security group(s) to revert to the NSX-determined security group(s).

Note When the Quarantine Policy is enabled, assign the vm-override-sg to your VMs before installingthe NSX agent on them. After you follow the process of installing the NSX agent and tagging the VM inAWS as overlay or underlay, remove the vm-override-sg SG from the VM. NSX Cloud will automaticallyassign the appropriate SG to NSX managed VMs thereafter. This step is necessary because it ensuresthe VM is not assigned the default SG while you are preparing it for NSX.

Quarantine Policy DisabledWhen Quarantine Policy is disabled:

n NSX Cloud does not assign any SG to the VMs launched in this VPC. You must assign theappropriate NSX Cloud SG in AWS to VMs to enable NSX Cloud functionality.

From the AWS console:

n n Assign vm-overlay-sg to VMs that you want to manage using the NSX overlay network.

n Assign vm-underlay-sg to VMs for which you want to use the underlay network provided byAWS.

n Assign vm-outbound-bypass-sg and/or vm-inbound-bypass-sg to VMs for which you want toenable Distributed Services Routing.

AWS Security GroupsThe following AWS Security Groups are created by NSX Cloud at the time of CGW deployment:

Table 7‑1. AWS Security Groups created by NSX Cloud for Workload VMs

AWS Security Group name Full Name

default Default Security Group

vm-underlay-sg VM Non-Overlay Security Group

vm-overlay-sg VM Overlay Security Group

vm-override-sg VM Override Security Group

vm-outbound-bypass-sg VM Outbound Bypass Security Group

vm-inbound-bypass-sg VM Inbound Bypass Security Group

Using NSX Cloud

VMware, Inc. 26

Recommendations for Brownfield and GreenfielddeploymentsBrownfield: It is recommend to disable Quarantine Policy if you already have VMs set up in your VPC andyou do not plan to have all your existing VMs to be managed by NSX. Disabling the Quarantine Policyensures that your existing VMs are not automatically quarantined by being moved to the “default” SG inAWS.

Greenfield: For greenfield deployments, it is recommended that you enable Quarantine Policy to allow allthreat detection workflows for your VMs to be managed by NSX Cloud.

Using NSX Cloud

VMware, Inc. 27

Using Advanced NSX CloudFeatures 8This chapter includes the following topics:n Enable Syslog Forwarding

n Access AWS Services in the Underlay Network

n Enable NAT on NSX-managed VMs

Enable Syslog ForwardingNSX Cloud supports syslog forwarding.

You can enable syslog forwarding for Distributed Firewall (DFW) packets on NSX-managed VMs.

Do the following:

Procedure

1 Log in to PCG using the jump host.

2 Type the nsxcli command to open NSX-T CLI.

3 Type the following commands to enable DFW log forwarding:

nsx-public-cloud-gateway> set gw-controller vm-log-forwarding enabled

nsx-public-cloud-gateway> set logging-server <server-IP-address> proto udp level info messageid

FIREWALL-PKTLOG

After this is set, NSX agent DFW packet logs are available under /var/log/syslog on PCG.

4 To enable log forwarding per VM, enter the following command:

nsx-public-cloud-gateway> set gw-controller vm-log-forwarding enabled <vm-id>

Reference: See Configure Remote Logging in the NSX-T Administration Guide

VMware, Inc. 28

Access AWS Services in the Underlay NetworkAWS Services such as S3, ELB, RDS, have IP addresses that cannot be accessed by NSX-managedVMs in overlay-mode. To overcome this limitation, NSX Cloud provides Distributed Services Routing(DSR).

DSR is a feature that allows services in the overlay network to have direct access to underlay services inAWS. It also allows underlay services to access VMs via the overlay network.

Procedure

1 To enable only outbound access from your VM, do the following:

a Add the nsx:directroute.[n] tag to the VM with the CIDR of the service for which you want toenable access.

2 To enable outbound and inbound access from and to your VM, do the following:

a Add the nsx:directroute.[n] tag to the VM with the CIDR of the service for which you want toenable access.

b Add the nsx:directinbound tag to the VM with the value true (case-sensitive).

You can add multiple outbound service prefixes/CIDRs using the nsx:directroute.[n] tag. TheVM will drop all traffic from IP addresses not listed in the tag value.

When you enable inbound services to this VM by attaching the nsx:directinbound tag, all theoutbound services can send traffic to this VM. You cannot choose which services will send inboundtraffic to the VM.

Example: DSR exampleFor example, if you want to enable S3 functionality on your VM in the us-west-2 region, add the followingtags:

Table 8‑1. Key Value

nsx:directroute.0 54.231.160.0/19

nsx:directroute.1 52.218.128.0/17

nsx:directroute.2 52.92.32.0/22

Using NSX Cloud

VMware, Inc. 29

Table 8‑2. AWS Tags for DSR

What you need todo... Use this Tag Key(s) Use this Tag Value Behind the Scenes

Allow Outbound Trafficfrom VM

nsx:directroute.[n] Provide one of the following:n IPv4 CIDR, e.g. 10.10.10.0/24n The string “vpc-cidr-block”.

This is mapped to the CIDR ofthe VPC this VM belongs to.

Within about a minute,the VM is added to theAWS security group“vm-outbound-bypass-sg”, whichpermits the appropriateoutbound traffic.

Allow Inbound andOutbound Traffic to andfrom this VM

1 nsx:directroute.[n]

2 nsx:directinbound

1 Provide one of the values foroutbound traffic.

2 Type in true (case-sensitive)

Within about a minute,the VM is added to theAWS Security Group:“vm-inbound-bypass-sg”.

Enable NAT on NSX-managed VMsNSX Cloud supports enabling NAT on NSX-managed VMs.

You can enable North-South traffic on VMs in overlay mode using AWS tags.

Procedure

u On the NSX-managed VM for which you want to enable NAT, apply the following AWS tag:

Key Value

nsx:publicip <EIP from AWS>, for example, 50.1.2.3 The EIP you provide here must be free to use and must not be assigned to any VM, even theworkload VM you want to enable NAT for. If you assign an EIP that was previously associated withany other instance or private IP address, NAT does not work. In that case, unassign the EIP, removethe nsx:publicip tag on the VM or interface, and add it again.

After this tag is applied, the following configurations take place behind the scenes:

1 A secondary IP address is allocated on the uplink interface of PCG. This IP address is associatedwith the EIP specified in the tag’s value.

2 One SNAT rule and one DNAT rule is created in NSX Manager mapping the overlay private IPaddress of this VM with the secondary IP address and vice versa. For example:

n SNAT: 192.168.10.25 -> 10.201.1.3

n DNAT: 10.20.1.3 -> 192.168.10.25

3 Two levels of NAT takes place.

For SNAT:

n From VM’s overlay IP address to PCG’s secondary IP address

Using NSX Cloud

VMware, Inc. 30

n From PCG’s secondary IP address to EIP in AWS

For DNAT:

n From EIP to PCG’s secondary IP address in AWS

n From AWS secondary IP address to the VM’s overlay IP address in PCG

eth2 uplink interface10.20.1.1 (primary IP)

10.20.1.2 (secondary IP for default SNAT)10.20.1.3 (secondary IP for VM floating IP)

EIP 50.1.2.3

NSX agent

OS

NAT

NSX PublicCloud

Gateway(CGW)

SNAT/DNAT rules on MP192.168.10.25 <-> 10.20.1.3

Workload VM

nsx-eth0 192.168.10.25

AWS IP address association50.1.2.3 -> 10.20.1.3

SNAT/DNAT rules on MP192.168.10.25 <-> 10.20.1.3

Using NSX Cloud

VMware, Inc. 31

Cheat Sheets andTroubleshooting 9This chapter includes the following topics:

n Onboarding Workflows

n Verify NSX Cloud Components

n AWS Tags for NSX Cloud

n NSX Agent Install Script Options and Uninstallation

n Undeploying PCG

n Troubleshooting FAQ

Onboarding WorkflowsThe workflows that allow NSX to manage workload VMs in your AWS cloud involve several steps to beperformed in-tandem in NSX Cloud and AWS. This table depicts them at a glance.

Enabling NSX to Access your AWS Inventory and Manage yourVMs

Table 9‑1. 1. Add your AWS account in CSM.

NSX Cloud Workflow AWS Workflow

1.1 From the NSX Cloud Dashboard, copy the URL of the JSONtemplate file.

See NSX Cloud workflow

See AWS Workflow 1.2. Create a new Stack in CloudFormation and use theJSON file copied in step 1.1.

See AWS Workflow 1.3. From the Outputs tab, copy IAMRoleARN, ExternalID,GatewayRoleName.

1.4. From the CSM dashboard, click Add Account. Provide adistinct name for the account, and the values from step 1.3.

See NSX Cloud workflow

See Chapter 2 Add your Public Cloud Inventory for detailed instructions.

VMware, Inc. 32

Table 9‑2. 2. Deploy PCG on a compute VPC in your AWS account.

NSX Cloud Workflow AWS Workflow

See AWS Workflow 2.1 .For the compute VPC you want to manage with NSX,create three (six, if enabling HA) subnets and ensure thisVPC has an Internet gateway with routing tables. Also ensurethe VPC has DNS routing and DNS names enabled.

Make a note of the PEM file for your AWS account.

Alternatively, use the CloudFormation template, from theResources tile on the NSX Cloud Dashboard, to create acompute VPC.

2.2. From the CSM dashboard, go to VPCs. Select the computeVPC and click Deploy Gateway. Select the PEM file for your AWS account, and select whether youwant to turn Quarantine Policy on or off.

See NSX Cloud workflow

2.3. Select whether you want to set up High Availability. Select the Availability Zone and the management, uplink, anddownlink subnets. Select an additional Availability Zone and thethree additional subnets in this zone if you picked HA.Click Deploy.

See NSX Cloud workflow

See AWS Workflow 2.4. Automatic: As part of PCG deployment, a set of SecurityGroups are created in your AWS account. A new Type A Record Set is added with the name: “nsx-gw.vmware.com” in AWS Route 53.

2.5. Automatic: As part of PCG deployment, a set of components --including two default Logical Switches are created in NSX Manager.

NSX Cloud Workflow

2.6. From NSX Manager: Attach DHCP servers to the defaultoverlay logical switch created in step 2.5. Also attach the auto-created tier-0 logical router to the overlay logical switch.

NSX Cloud Workflow

See Chapter 2 Add your Public Cloud Inventory for detailed instructions.

Table 9‑3. 3. Enable NSX to manage your VM (detailed instructions).

NSX Cloud Workflow AWS Workflow

See AWS Workflow 3.1. Download and Install the NSX-agent on your Windowsand Linux VMs.

See AWS Workflow 3.2. Tag VMs with the key nsx:network with the value ofeither the logical switch UUID (overlay VMs) or default(non-overlay VMs)

3.3. Automatic: After you install the NSX-agent on your VM and tagit in AWS, the VM is marked as NSX-managed and other essentialNSX entities are created.

See NSX Cloud Workflow

See Chapter 3 Prepare your VMs for NSX for detailed instructions.

Using NSX Cloud

VMware, Inc. 33

Verify NSX Cloud ComponentsIt is a best practice to verify that all components are up and running, before deploying in a productionenvironment.

Verify whether NSX Agent is connected to CGWTo verify that the NSX Agent on your workload VM is connected to CGW, do the following:

1 Type the nsxcli command to open NSX-T CLI.

2 Type the following command to get the gateway connection status:

get gateway connection status

Public Cloud Gateway : nsx-gw.vmware.com:5555

Connection Status : ESTABLISHED

Verify the VM’s Interface/Network ModeThe VM on which the NSX agent is installed, can have one of two switch modes -- overlay or non-overlay.Verify as follows:

1 Type the nsxcli command to open NSX-T CLI.

2 Type the command to view the switch mode.

get vm-network-mode

VM-Network-Mode : overlay

Interface : eth0

The nsx:network key must have the value default (non-overlay) or <logical_switch_ID_from_NSX-T> for the overlay Logical Switch ID.

Verify VM Interface Tag in AWSThe Windows and Ubuntu VMs must have the correct tags to connect to CGW.

1 Log in to the AWS console.

2 Verify the VM eth0 or interface tag.

AWS Tags for NSX CloudNSX Cloud uses AWS Tags extensively to allow NSX to manage your VMs and enable other services.

Important You can assign tags either to the VM or to an interface. Once you assign the mandatorynsx:network tag to either the VM or an interface, you must assign the other tags to the same.

Using NSX Cloud

VMware, Inc. 34

Table 9‑4. AWS Tags for NSX Cloud

Mandatory or Optional AWS Tag: Key AWS Tag: Value Purpose

Mandatory nsx:network n Overlay VM: UUID of theLogical Switch attachedto this VM

n Non-overlay VM:default

When this tag is applied to aVM with the NSX agentinstalled on it, the VM becomesNSX-managed.

See Chapter 3 Prepare yourVMs for NSX for detailedinstructions.

Optional nsx:publicip Elastic IP address from AWS This tag enables NAT on theVM.

See Enable NAT on NSX-managed VMs for detailedinstructions.

Optional nsx:directroute.[n] IPv4 CIDR or vpc-cidr-block

This tag enables outboundDistributed Services Routing.

See Access AWS Services inthe Underlay Network fordetailed instructions.

Optional nsx:directinbound true (case-sensitive) This tag, along with thensx:directroute.[n] tag,enables inbound DistributedServices Routing.

See Access AWS Services inthe Underlay Network fordetailed instructions.

NSX Agent Install Script Options and UninstallationThe NSX Agent installation script provides configurable options. This table lists these options.

NSX Agent Install Script Options for Windows VMsTable 9‑5.

Option Description

-gateway <ip|dns> NSX public cloud gateway IP or DNS name.

Specify this option if you want to use an IP address for the PCG.The default DNS name of the PCG is nsx-gw.vmware.localwhich is used if this parameter is not specified.

-noStart true You can create an AMI of the VM after the NSX agent isinstalled on it. Run the install script with this option. Then fromthe AWS console, create an AMI of this VM.

-downloadPath <path> This is the path to the directory in which the files should bedownloaded. If the path includes escape characters, enclosethem in single quotation marks.

Default = %temp%

Using NSX Cloud

VMware, Inc. 35

Table 9‑5. (Continued)

Option Description

-silentInstall <true/false> If this is set to true, the script runs a silent installation.

Default is false

-noSigCheck <true/false> This allows you to specify whether to check the signatures onthe binaries or not.

Default = false

-logLevel <value> This allows you to specify the log level for NSX components

Default = 1

Verbose = 3

-operation <install/uninstall> This allows you to specify the operation to perform: install oruninstall

Default = install

-bundlePath <path> This allows you to specify the local path to the NSX VM agentbundle

Default option is to download the bundle from PCG.

Uninstalling NSX agent from a Windows VM1 Remote log in to the VM using RDP.

2 Run the installation script with the uninstall option:

\nsx_install.ps1 -operation uninstall

NSX Agent Install Script Options for Linux VMsTable 9‑6.

Option Description

--gateway <ip|dns> NSX public cloud gateway IP or DNS name.

Specify this option if you want to use an IP address for the PCG.The default DNS name of the PCG is nsx-gw.vmware.localwhich is used if this parameter is not specified.

--no-start You can create an AMI of the VM after the NSX agent isinstalled on it. Run the install script with this option. Then fromthe AWS console, create an AMI of this VM.

--uninstall Run the script with this option to uninstall the NSX agent.

Undeploying PCGYou can undeploy PCG from a VPC, but remember to delete all logical entities associated with it first.

Using NSX Cloud

VMware, Inc. 36

Undeploying PCGTo undeploy PCG, click Undeploy Gateway from the VPC. The default entities created by NSX Cloud areremoved automatically when a PCG is undeployed.

Delete all the logical entities you created in NSX Manager before undeploying the gateway. Refer to thelist below to find your entities to delete:

n AWS: DNS entry in route 53

n DDI: DHCP profile

n Routing: SNAT rule

n Routing: static Router

n Routing: Logical Router Port

n Routing: Logical Router

n Fabric-Nodes: Edge Cluster

n Fabric-Nodes: Transport Nodes

n Fabric-Nodes: Edges

n Fabric-Profiles: PCG-Uplink-HostSwitch-Profile

n Switching: Logical Switch ports

n Switching: Logical Switches

n Fabric-Transport Zones: Transport Zones

n Switching: PublicCloud-Global-SpoofGuardProfile

Troubleshooting FAQThis lists some frequently asked questions.

How do I move an overlay VM from one logical switch to anotherlogical switch?

Change the value to the new logical switch UUID in the AWS tagging workflow for the nsx:network tag.See Apply the nsx:network tag to VMs in AWS

My NSX Cloud Dashboard reflects the new features, and thedocumentation lists them, but I don't see any changes in CSM andNSX Manager. What am I missing?

Using NSX Cloud

VMware, Inc. 37

Changes are reflected in CSM and NSX Manager after the upgrade process has completed. The Upgradeand Maintenance tile on the NSX Dashboard displays the upgrade status. When upgrade succeeds, allnew features and bug-fixes are available.

I tagged my VM correctly and installed the agent but logicalswitches are not showing up in NSX Manager and my VM isquarantined. What should I do?

If you encounter this problem, try the following:

n Check whether the AWS tag’s value is correctly typed in. It is case-sensitive.

n Refresh the AWS account from CSM.

What could be the reason for the NSX agent installation onUbuntu 14.04 to fail?

If you are trying to install the NSX agent on an instance where ec2-net-utils package is already present,NSX agent installation may fail. Remove the package ec2-net-utils from the instance and retry installingthe NSX agent.

Are IPFIX and Port Mirroring only allowed to a remote VM withinthe same VPC?

Yes. IPFIX and Port Mirroring are features where local traffic stats or local traffic is sent to a remote VM.NSX Cloud mandates the remote VM to be in the same VPC in the same VPC subnet/CIDR.

What should I do if can ping my Linux workload VM, but cannotaccess it through SSH?

n Log in to the VM over SSH using port 8888.

n Change the namespace to nsx-root by running the command: ip netns exec nsx-root bash

n Carry out troubleshooting.

What should I do if I cannot access my Linux workload VM?

n Attach a secondary NIC to the workload VM and the jumphost VM in the same subnet.

n Access the VM over the secondary NIC and carry out the necessary troubleshooting.

n Remove the secondary NIC.

Using NSX Cloud

VMware, Inc. 38

Using the Cloud ServiceManager 10See: Using the Cloud Service Manager (CSM)

Using the Cloud Service Manager.

VMware, Inc. 39

Using NSX Manager 11See: Using NSX Manager

Using NSX Manager.

VMware, Inc. 40