Creating NAT and DFW Rules in NSX+

Site B (nsxmanager-01b.corp.vmw) was onboarded after Site A (nsxmanager-01a.corp.vmw) in my previous posts. There is already an Edge cluster deployed and all ESXi hosts are prepped in this installation.

If you’ve ever configured NAT and DFW rules in NSX before, you’ll find the process almost identical in NSX+.

My goal in this series of posts it is to configure a T0, T1, segments, DFW and NAT rules to support a three-tier web app. There will also be some BGP configuration to allow for routes to be shared outside of the local NSX environment.

There is a three-tier app at Site B that is using NSX networking. The app consists of three web VMs, and app VM, a DB VM and a load balancer (LB) VM. All VMs are on different networks (the three web VMs are on the same network).

The app is arbitrarily named cda. There is a similar app at Site A named dist but most work in NSX+ will be with the cda app VMs in Site B.

app network172.32.1.0/24
db network172.32.2.0/24
lb network172.32.0.0/24
web network172.32.3.0/24
App VMscda-app-01
DB VMScda-db-01
LB VMscda-lb-01
Web VMScda-web-01
cda-web-02
cda-web-03
DNS Server192.168.110.10
NTP Server192.168.100.1

Traffic Flow:

  • HTTP/HTTPS (80/443), from any source to VMs on the lb network
  • HTTP (80), from VMs on the lb network to VMs on the web network
  • 8443/TCP, from VMs on the web network to VMs on the app network
  • 8080/TCP, from VMs on the app network to VMs on the db network
  • DNS (53), from VMs on any configured network to 192.168.110.10
  • NTP (123) from VMs on any configured network to 192.168.100.1

The core NSX infrastructure is already deployed at Site B. Originally, all necessary components were configured on the LM at Site B but this has all been torn down so it can be recreated in NSX+.

Once the T0 has been created at Site B, you can move on to creating T1s.

Ensure that you are in the Instance-specific view in NSX+ (not the Global view).

Only two NAT rules are needed for the three-tier app at Site B. 

In the NSX+ UI, navigate to Networking Network ServicesNAT.

Ensure that the T0 at Site B is selected under the Gateway dropdown.

Click the Add NAT Rule button. Configure the form as appropriate.

Click the Save button.

Repeat for any other needed NAT rules. For the three-tier app at Site B, only one additional DNAT rule is needed.

The first step to creating DFW rules is to create some groups to more easily organize the VMs in the three-tier app.

In the NSX+ UI, navigate to Security Inventory Groups.

Click the Add Groups button. Supply a meaningful name.

Click Set under Compute Members.

For the purposes of this example, leave Group Type at Generic. Click the Add Criterion button.

From this configuration, you can see that the group membership criteria is based on the VM name starting with cda-web.

Click the Apply button.

Click the Save button.

Click View Members under Computer Members to see which VMs are in the group.

Click the Close button.

Repeat the above steps to create groups for the App VMs (cda-app), DB VMs (cda-db) and LB VMs (cda-lb).

Navigate to Security Policy Management Distributed Firewall > Category Specific Rules.

Click Add Global Policy. Provide a meaningful name.

With the new global policy selected, click the Add Rule link. Provide a meaningful name.

Click in the Destinations section for the new rule. Find an select the appropriate group (LB VMs in this case since the rule is “Allow Any to LB”

Click the Apply button.

Click in the Services section for the new rule. Find and select the appropriate services (HTTP and HTTPS since the destination is LB VMs).

Click the Apply button.

Create more rules as necessary.

Click the Publish button when you’re done creating rules.

On the local NSX Manager, you can see these same rules with an identifier noting that they were created in NSX+.

You can examine the /var/log/proton/nsxapi.log file on the local NSX manager to see evidence of the groups and rules being created.

2023-08-02T16:05:25.213Z  WARN Executors-1-1 Executors 4652 - [nsx@6876 comp="nsx-manager" level="WARNING" subcomp="manager"] ScheduledTaskQueue size getting large queue EventReportProcessor-1- size 205
2023-08-02T16:05:25.751Z  INFO nsxe-alarms-thread ComputeManagerFinderImpl 4652 FABRIC [nsx@6876 comp="nsx-manager" level="INFO" subcomp="manager"] Returning compute managers by VcLink having true, as 0
2023-08-02T16:05:25.943Z  INFO ClientReceiverFlowHandler-0 ClientDataReceiver 4652 - [nsx@6876 comp="nsx-manager" level="INFO" subcomp="manager"] processMessagesForSite: site=aa36902b-7317-4c29-b126-ddbf1f196577, flow=FlowIdentifier{role='Policy', nameSpace='GM_2_LM'}, message=Delta data. Source site=aa36902b-7317-4c29-b126-ddbf1f196577
   PUT:Table=GroupAttributes Key=/orgs/8f238d3d-ade7-4711-9f9d-d95e130d454b/projects/default--EPSG_Pre-Prod_Trial_Instance/infra/domains/global/groups/LB_VMs/attributes/LB_VMs
   PUT:Table=Group Key=/orgs/8f238d3d-ade7-4711-9f9d-d95e130d454b/projects/default--EPSG_Pre-Prod_Trial_Instance/infra/domains/global/groups/LB_VMs
   PUT:Table=Span Key=/orgs/8f238d3d-ade7-4711-9f9d-d95e130d454b/projects/default--EPSG_Pre-Prod_Trial_Instance/infra/span/orgs-8f238d3d-ade7-4711-9f9d-d95e130d454b-projects-default--EPSG_Pre-Prod_Trial_Instance-infra-domains-global-groups-LB_VMs, source ID=left: 2589930
right: 700027180670779424
, destination ID=left: 19031689
right: 700027181226524848

I also needed rules for the VMs in the three-tier app to be able to connect to DNS and NTP servers. The process for setting these up was the same as the other rules.

Leave a Comment

Your email address will not be published. Required fields are marked *