Essential NSX-T Data Center entities are created and configured in NSX Manager and security groups are created in your public cloud after the PCG is successfully deployed.

NSX Manager Configurations

The following entities are automatically created in NSX Manager:

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

  • The PCG is added to Edge Cluster. In a High Availability deployment, there are two PCGs.

  • The PCG (or PCGs) is registered as a Transport Node with two Transport Zones created.

  • Two default logical switches are created.

  • One Tier-0 logical router is created.

  • A Firewall Section is created with the name Default LR Layer3 Section.

  • Two Firewall Rules are created under this Firewall Section, one for each PCG:

    • preferred:VPN Firewall Rule

    • VPN Firewall Rule

    Note:

    If you deployed only one PCG, only one firewall rule is created. These Firewall Rules are required for implementing Service Insertion.

  • An IP Discovery Profile is created. This is used for overlay logical switches (not supported in the current release).

  • A DHCP Profile is created. This is used for DHCP servers (not supported in the current release).

  • A default NSGroup with the name PublicCloudSecurityGroup is created that has the following members:

    • The default VLAN logical switch.

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

    • IP address.

  • Three default distributed firewall (DFW) rules are created:

    • LogicalSwitchToLogicalSwitch

    • LogicalSwitchToAnywhere

    • AnywhereToLogicalSwitch

    Note:

    These DFW rules block all traffic and need to be adjusted according to your specific requirements.

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 (status shows Up with a green dot).

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

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

    • Traffic type VLAN: this connects to the PCG uplink

    • 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 logical router added to the Edge Cluster.

Important:

Do not delete any of the NSX-created entities.

Public Cloud Configurations

In AWS:

  • In the AWS VPC, a new Type A Record Set gets added with the name nsx-gw.vmware.local into a private hosted zone in Amazon Route 53. The IP address mapped to this record matches the Management IP address of the PCG which is assigned by AWS using DHCP and will differ for each VPC. This DNS entry in the private hosted zone in Amazon Route 53 is used by NSX Cloud to resolve the PCG's IP address.

    Note:

    When you use custom DNS domain names defined in a private hosted zone in Amazon Route 53, the DNS Resolution and DNS Hostnames attributes must be set to Yes for your VPC settings in AWS.

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

In AWS and Microsoft Azure:

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

Table 1. Public Cloud Security Groups created by NSX Cloud for PCG interfaces

Security Group name

Available in Microsoft Azure?

Available in AWS?

Full Name

gw-mgmt-sg

Yes

Yes

Gateway Management Security Group

gw-uplink-sg

Yes

Yes

Gateway Uplink Security Group

gw-vtep-sg

Yes

Yes

Gateway Downlink Security Group

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

Security Group name

Available in Microsoft Azure?

Available in AWS?

Descriptiom

quarantine

Yes

No

Quarantine security group for Microsoft Azure

default

No

Yes

Quarantine security group for AWS

vm-underlay-sg

Yes

Yes

VM Non-Overlay security group

vm-override-sg

Yes

Yes

VM Override Security Group

vm-overlay-sg

Yes

Yes

VM Overlay security group (this is not used in the current release)

vm-outbound-bypass-sg

Yes

Yes

VM Outbound Bypass Security Group (this is not used in the current release)

vm-inbound-bypass-sg

Yes

Yes

VM Inbound Bypass Security Group (this is not used in the current release)