vxlearners

This blog will discuss how micro-segmentation will be enforced on OrgVDC using NSX-T. However, we have already integrated NSX-T with VMware cloud director in the previous series with and without data center groups. Using the concept of data center groups, we will configure three stretch segments, one for “Web”, the second one for “APP” and another one for “Web”. All these segments will connect to a single Stretch Tier-1 gateway. We will leverage the distributed firewalling feature of NSX-T to control east-west traffic, which will restrict traffic between these three segments.

Topology Diagram

In this scenario, we already deployed one Parent T0 gateway, which will have 2 nodes at the primary site and two at the secondary DC. A separate VRF Tier-0 has been created for organization “Organization”, which will provide north-south communication. We have also deployed three NSX-T overlay segments, which are stretched across OrgVDC-1 and Org-VDC-2, connected to stretch Tier-1 gateway (T1-VRF-VDC-1).

NSX-T Overlay Segment	Subnet	Gateway (T1-VRF-VDC-1)
Web-Segment	10.1.1.0/24	10.1.1.1/24
App-Segment	10.1.2.0/24	10.1.2.1/24
DB-Segment	10.1.3.0/24	10.1.3.1/24

In the current situation, VMs in Web-Segment, App-Segment, and DB-Segment can communicate with each other either via TCP, UDP, or IP. However, we will use the DFW (Distributed Firewalling) feature of NSX-T to enforce specific traffic between these VMs. For instance, a VM in Web-Segment can “SSH” into VM in App-Segment, but can’t “SSH” into DB-VM. Similarly, the VM in App-Segment can “SSH” into VM in DB-segment. All other traffic will be blocked using the NSX-T DFW feature.

Pre-validation

Before proceeding with some pre-validation, below are the IP addresses of three VMs.

Web-VM	10.1.1.100
APP-VM	10.1.2.100
DB-VM	10.1.3.100

In this step, we will validate network connectivity between all VM’s in different NSX-T overlay segments like Web-Segment, App-Segment, and DB-Segment.

Firstly, we will check network connectivity between Web-VM, App-VM, and DB-VM using “SSH” and “ICMP”.

Verifying the IP address of Web-VM.

Checking “SSH” and “ICMP” connectivity of “App-VM” from Web-VM.

Checking “SSH” and “ICMP” connectivity of “DB-VM” from Web-VM.

Verifying the IP address of App-VM.

Checking “SSH” and “ICMP” connectivity of “Web-VM” from App-VM.

Checking “SSH” and “ICMP” connectivity of “DB-VM” from App-VM.

Verifying the IP address of DB-VM.

Checking “SSH” and “ICMP” connectivity of “Web-VM” from DB-VM.

Checking “SSH” and “ICMP” connectivity of “App-VM” from DB-VM.

Configuring Micro-Segmentation on VCD using NSX-T

In this step, we will configure all logical constructs essential for configuring micro-segmentation in VCD using NSX-T.

Configuring Security Tag

This step will configure a “tag” on all VMs. To assign tags in VCD, Go to Networking, click on security tags, and assign tags to our VMs, the same tags will be visible.

web-tag	Web-VM
app-tag	App-VM
db-tag	DB-VM

In this step, we will configure “Web-tag” and assign it to “Web-VM.

In the second step, we will configure “App-tag” and assign it to “App-VM.

In the last step, we will configure “DB-tag” and assign it to “DB-VM.

Verify the tag creation in both VCD and NSX-T

The same “tags” has been configured in NSX-T. To verify, login into NSX-T, go to inventory and then go to tags to verify the creation of tags on VCD.

NB: “VCD” tag is automatically created in NSX-T when NSX-T is integrated.

Configuring Security Groups

In this session of the blog, we will configure “Dynamic Group”, which is essential to configure micro-segmentation
To configure dynamic groups, go to the Networking tab of VCD, data center groups, and expand the existing data center group. We will assign a security group to our VM from VCD, same tags will be visible on NSX-T.

Dynamic groups will be created in VCD using the below criteria.

Web-SG	Rule	VM Tag	Equals	web-tag
App-SG	Rule	VM Tag	Equals	app-tag
DB-SG	Rule	VM Tag	Equals	db-tag

Creating a ‘Dynamic Security group” for web-tag (Web-VM).

Creating a ‘Dynamic Security group” for app-tag (App-VM).

Creating a ‘Dynamic Security group” for db-tag (DB-VM).

Verifying the status of newly created Security groups in VCD.

Verifying the status of newly created Security groups in NSX-T.

Configuring Distributed Firewall rules in NSX-T for VCD

In this step, we will configure firewall rules to allow only “SSH” traffic between the three VMs (Web-VM, App-VM, and DB-VM). All these policies will be created in NSX-T to allow appropriate traffic, which will be enforced on the “vNIC” of the VMs. However, in an earlier section of this documentation, we have already created the required logical constructs, which are essential to enforce security policies from NSX-T.

Adding a security policy

In order to create a security policy, go to security, then to distributed firewalls and create a new security policy.

Security Policy Name	VCD micro-segmentation
Applied to	DFW

In order to make these policies effective, publish these rules.

Adding rules in security policy

In this section, we will create rules to allow, drop or reject traffic between virtual machines belonging to the same security group or a different security group.

Rule Name	Source	Destination	Services	Applied To	Action	Rule	Logging
SSH to Web-VM	Any	Web-SG	SSH	DFW	Allow	Enabled	Yes
SSH to App-VM from Web-VM	Web-SG	App-SG	SSH	DFW	Allow	Enabled	Yes
SSH to DB-VM from APP-VM	App-SG	DB-SG	SSH	DFW	Allow	Enabled	Yes
Block ICMP	Any	Any	ICMP	DFW	Reject	Enabled	Yes

NB: In the real scenario, the services would be actual application ports like HTTP, HTTPS, MySql, and many more.  Micro-segmentation in VCD is configured from NSX-T. However, all its logical constructs like tags and SG are configured from VCD. Gateway firewalls will be configured from VCD, which will discuss in the next blog.

NB: Rule-id is auto-generated by NSX-T.

To take privileges of micro-segmentation, make sure to set the action to either drop or reject the default rule, which in our case has been configured as “reject”.

Make sure to add VCD SG, which has to be created by the VCD tag, and in the firewall exclusion list, otherwise, you may lose the connectivity to VCD.

Post-validation

In this step, we validate the previously configured firewall rules, by generating the action traffic.

We tried to SSH into “App-VM” from “Web-VM” and it was successful (matches rule number 2 of our security policy), however, when we tried to ping “App-VM” from “Web-VM” it was unsuccessful, as it matches rule-4 of security policy.

We tried to SSH into “DB-VM” from “App-VM” and it was successful (matches rule number 3 of our security policy), however, when we tried to ping “DB-VM” from “App-VM” it was unsuccessful, as it matches rule-4 of security policy.

However, when we tried to SSH and ping DB-VM from Web-VM, all traffic is rejected because it matches the default rule (SSH traffic) and rule-4 of the security policy to drop ICMP traffic.

We tried to SSH into “Web-VM” from “DB-VM” and it was successful (matches rule number 1 of our security policy), however, when we tried to ping “Web-VM” from “App-VM” it was unsuccessful, as it matches rule-4 of security policy.

Post-Validation from NSX-T

In this part, we will explore more options to validate the enforcement of security policies like trace f

low(an inbuilt feature of NSX-T).
In this scenario, we have generated ICMP traffic from Web-VM to App-VM, and it was rejected by rule-id 2028 (auto-generated by NSX-T), rule-4 of the security policy.

In the second scenario, we generated ICMP traffic from Web-VM to DB-VM, and it was rejected by rule-id 2028 (auto-generated by NSX-T), rule-4 of the security policy.

In the third scenario, we generated SSH traffic from APP-VM to DB-VM, and it was allowed by rule-id 2027 (auto-generated by NSX-T), the rule- of security policy.

In the last scenario, we generated SSH traffic from DB-VM to Web-VM, and it was allowed by rule-id 2025 (auto-generated by NSX-T), rule-2 of the security policy.

In Summary: 

In this blog, we have discussed how micro-segmentation can be enforced from NSX-T to VCD OrgVDC. All necessary components required to create security policies, and rules are configured from VCD (OrgVDC) like tags, dynamic security groups, and so on. Distributed firewalling feature of NSX-T provides micro-segmentation to OrgVDC. However, gateway firewalling can be configured from OrgVDC, which we will talk about in the next blog in more detail. We have also explored the NSX-T inbuilt feature of trace flow to validate the enforcement of firewalls on the vNIC of VMs.

In the next couple of blogs, we will talk about gateway firewalling (to control North-South communication) in VCD. All necessary configurations for Gateway Firewall will be done on VCD.