Any customer can benefit from the automation enabled by this wizard-assisted operation, as the following example highlights.
Imagine a customer has already deployed their NSX-T infrastructure through the wizard-driven process just described. As a next step, they will create some basic firewall rules, and to do that, they need to define some infrastructure services.
Now say they want to deploy a typical set of network services, including the following:
These services may run on VMs or physical servers.
The following figure shows the diagram of the NSX configuration described in this section:
Under host preparation, the customer would select Create Firewall Rules, as shown in the following figure. From there, they can create infrastructure groups dedicated to these types of network services.
They would then start adding a DHCP service, which is done through a VM in this case.
Deploying network services is as simple as selecting the VM and providing the basic info needed in the fields provided, such as Group Name and NSX Tag.
Once the DHCP service is created, the customer can add a second one, which is DNS in this example. The Group Dashboard shows an existing DHCP one, conformed by 1 VM. The customer would add a second Group—a DNS server.
For the DNS service, the customer would use a physical box. In that case, they need to provide the IP address of that server, as seen in the following figure.
This server is external to the virtualized environment in which their NSX-T lives.
In just a few clicks, the customer has added DHCP and DNS services to their environment, compliant with the firewall rules defined in our NSX policies.
To close out this example, let’s say the client wants to incorporate a custom group that may respond to specific needs of that organization. This option provides the flexibility needed to go beyond the typical infrastructure services such as DNS, DHCP, or Active Directory.
Imagine they name this new Group myService and use a dvportgroup in this occasion.
The customer would select a specific distributed virtual port Group and assign it to the new infrastructure service.
As a last step, once the customer has their NSX infrastructure and basic services deployed, they would create the environment that is going to consume those services.
The customer may have designed a scenario with the following groups: Production, Development, and Payment Card Industry (PCI).
They would start by defining a Production Group, formed by two VMs: prod.web and prod.backend.
They would then do the same with Development and PCI, choosing the VMs that are part of each group.
It is important to highlight the relevance of the NSX tag. For any VM the customer creates in the future, if they tag it with Production, Development, or PCI NSX, it will be included in that workload group. This makes it subject to all the security and communications implications that it may have.
For this example, the customer ends up with three groups, with the corresponding VMs inside of them, as seen in the following figure.
The client can go one step further by defining which applications run inside a particular Group. They can create a myApp application group with the two production VMs in it: prod.web, and prod.backend.
The next natural step would be to define the communications that can happen between the elements in our environment. The customer can create a communication schema that allows for the following:
The customer would implement that design assigning which environment groups (Prod, Dev, PCI) can talk to the three defined infrastructure groups (DHCP, DNS, myService). This is shown in the following figure.
The result is shown in the following figure, where there are several workload groups that can talk to certain infrastructure groups.
The last step in this deployment and configuration process is to define the communication strategies for applications.
The customer has their myApp running inside the Production Group and wants to limit the traffic the application admits. They would define it to admit just HTTPS traffic.
To do so, they would create a strategy for myApp to reject all traffic and add one exception: port 443, HTTPS traffic, as shown in the following figure.
Once all the rules are created for infrastructure, workload, and application Groups as well as the communication policies, the customer has another opportunity to review these strategies before they are published in the NSX DFW. This checkpoint is shown in the following figure.
This is how those policies will look after they have been published. As always, even after going live, customers can come back and review, edit, any policy or rule that needs modification, as shown in the following figure.
A major advantage of this NSX distributed firewall over a physically segmented network is that the firewall is instantiated in every vNIC of every VM, allowing to define a granular network configuration and segmentation no matter where the VM or their connectivity may be. Also of relevance is to remember that all rules and existing tags move with VMs when vMotioned. If we create more instances of a specific VM (prodbackend or prod.web) to increase the solution scalability, just assigning the proper tags to them will make NSX apply all the associated rules.
Customers can apply firewall rules specific to each business-defined network zone, as seen in the following figure.