Projects in NSX and NSX+ provide a mechanism to provide multi-tenancy. An NSX+ project will be directly related to a CSP project. An NSX+ project configuration will be synced with appropriate local NSX managers based on site membership.
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 network | 172.32.1.0/24 |
| db network | 172.32.2.0/24 |
| lb network | 172.32.0.0/24 |
| web network | 172.32.3.0/24 |
| App VMs | cda-app-01 |
| DB VMS | cda-db-01 |
| LB VMs | cda-lb-01 |
| Web VMS | cda-web-01 cda-web-02 cda-web-03 |
| DNS Server | 192.168.110.10 |
| NTP Server | 192.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
Note: I had to tear down DFW rules, Segments and T1 created for Site B to be able to recreate them in the context of a project.
As an Org Admin, at VMware Cloud Services Platform (CSP), navigate to Identity & Access Management > Projects.
You can see that there are no projects in this org. That’s not entirely true as there is a default project in every org but you have no ability to manipulate it, and you can’t create a project under the defaul org. Also, you don’t want to add a project here but in NSX+.
Launch the NSX+ service. At the top of the page, you will see that the current project is default–EPSG_PRE-Prod_Trial_instance, which corresponds to the name of the Instance created earlier. This project is created by default and there is very little you can do with it compared to user-created projects.
Click the Manage link under Projects.
Click the Add Project button. Provide an approprite name
Click the Save button. Click No when asked if you want to keep editing.
Click the Add Project button again to create a second project. Give it an appropriate name.
Click the Save button.
Click Yes to keep editing this project.
Set the Site as appropriate. This screenshot is not accurate as my intention was to have the cda project be applicable only to Site B. You can see Site B in the dropdown.
Click Set under Users.
Click the Add Role Assignment button. Select an appropriate user from the User dropdown.
Click Set under Role/Scope.
Click the Add Role button. Chose an appropriate role for the user.
Click the Add button.
Click the Apply button.
Click the Save button.
Click the Close button.
You can see that I had correctly set the Site to Site B in the above screenshot.
Under Site, click the Add Site button. Select the appropriate site (Site B for this example). Additionally, set the appropriate T0 and Edge Clusters.
Click the Save button. Click the Close Editing button.
I repeated the above steps to create another project named dist, assign the dist project to Site A, and set a different user as the project admin
You can check the local NSX manager to see that the projects are available there now too.
And back in CSP, you will see that both projects exist there now:
In CSP, click the View Details link under the CDA project.
Note that NSXPlus is listed under Activated Services for this project, since the project was created within NSX+.
Navigate to Identity & Access Management > Active Users and select one of the new users. You should see that the user now has the NSX+ Project Admin service role.
Log in to CSP as one of the this user and launch the NSX+ service.
At this point, I went through the steps in my previous posts to create the T1 and segments. I found that any VMs attached to the segments were not able to talk to their default gateway (an interface on the T1). I discovered that there were some default DFW rules in place for the project that was created.
Note that the last rule is set to DROP and there is no rule that will allow anything in the project to talk to anything outside of the project. I was curious about the PROJECT-cda-default group though.
This group can’t be edited.
Digging into the documentation, I found that this is expected and that this rule I was poking at is only to allow VMs in the project to communicate with other VMs in the project.
The following blurb from the docs link above is the most relevant:
The default DFW policy ensures that VMs within a project can only reach other VMs in the same project, including the DHCP server. Communication with VMs outside the project is blocked. The VMs that are connected to the segments inside the project cannot ping their default gateway, by default. If such a communication is required, you must add new rules or modify existing rules in the default DFW policy.
I changed the last DROP rule to ALLOW (as it was the simplest option) and traffic started flowing as expected.
I was also able to go through the IDS configuration in the same manner as noted in my previous post within the user-created project and it worked identically to how it worked in the default project.