VMware NSX and Micro-Segmentation

What is Micro-Segmentation?

When it comes to SDN micro-segmentation is one of the biggest use cases/features that it has to offer. But what is micro-segmentation?

In its purest form,

Micro-Segmentation is a security technique that further isolates workloads/segments, allowing for finer-grained security controls to be applied.

Traditionally, network segmentation was achieved via the grouping of workloads. These workloads were placed onto a segment and mapped to a VLAN/L3 subnet. Egress/Ingress access control to the segment would then be performed via a perimeter firewall.

However, this model of segmentation presents a number of issues, such as:

• Isolation Scope - East-West communication within the segment was still possible. Therefore providing an attack surface should a compromise occur.
• Firewall Point - Traffic still needed to be sent over the network to the firewall before being denied or permitted.
• Administration - Attempts to solve these issues, such as adding more firewalls, adding host-based firewalls etc all resulted in an increase to administrative complexity.

Note: This article is based upon NSX 6.4

Figure 1 - Traditional Segmentation.

The Distributed Firewall (dFW)

NSX provides micro-segmentation via the distributed firewall aka dFW. The key points to note around dFW are:

• It is a host-based kernel module, rather than a VM.
• Provides micro-segmentation by placing a stateful firewall at the vNIC level of each VM
• Enforces access control directly at the VM level, resulting in traffic never having to reach the logical switch.
• Firewall rules are pushed out via the NSX manager, therefore, the NSX control cluster/UWA are not involved in the communication.
• Communication from the NSX manager and ESXi hosts is performed via the AMQP (Advanced Message Queueing Protocol) and the channel is secured using SSL.
• On an ESXi host, the VSFWD (vShield Firewall Daemon) process establishes and maintains the SSL connection to the broker.^[1]

Figure 2 - Distributed Firewall (dFW).

Firewall Rules

Firewalls rules can be added, amended and applied within Networking and Security > Firewall.

Figure 3 - dFW rules.

Security Groups/Tags

NSX provides two key features that around the grouping and defining of assets that you want to include within your firewalls policies. They are:

• Security Groups - Allows you to match based on computer OS, computer name, VM name, or Security tag. Security groups are then added as either the source or destination within the security policy.
• Security Tags - Allows you to tag a VM, this tag can then be referenced within a security group.

Note: Security groups and security tags are configured within Network and Security > Groups and Tags.

NSX Manager CLI

The NSX Manager provides a centralized method (via CLI) to query and obtain information about the distributed firewall that can be vital when troubleshooting NSX micro-segmentation.

Below provides some examples of the commands and information that can be obtained via the NSX manager.

Display Clusters

To show the clusters and the firewall statuses, we run the following command:

nsxmgr.packetflow.local> show dfw cluster all
No.  Cluster Name   Cluster Id               Datacenter Name   Firewall Status          Firewall Fabric Status
1    Compute        domain-c168              DC1               Not Ready                UNKNOWN
2    NFV-Control    domain-c173              DC1               Enabled                  GREEN
3    NFV-Data       domain-c175              DC1               Enabled                  GREEN
4    NFV-Edge       domain-c181              DC1               Enabled                  GREEN
5    Management     domain-c7                DC1               Not Ready                UNKNOWN

Display Hosts within Cluster

Next, to show each host within the cluster and their firewall statuses we run:

nsxmgr.packetflow.local> show dfw cluster  domain-c173
Datacenter: DC1
Cluster: NFV-Control
No.  Host Name      Host Id                  Installation Status      Firewall Fabric Status
1    172.29.111.1   host-364                 Enabled                  GREEN
2    172.29.111.2   host-366                 Enabled                  GREEN

Display VMs on Host

To confirm the VMs on the host and the corresponding VM Id, we run the following command:

nsxmgr.packetflow.local> show dfw host host-364
Datacenter: DC1
Cluster: NFV-Control
Host: 172.29.111.1
No.  VM Name     VM Id     Power Status
1    server001   vm-483    on

Display VM Details

Using the VM Id we can run the following to obtain the Vnic and Filter details.

nsxmgr.packetflow.local> show dfw vm vm-483
Datacenter: DC1
Cluster: NFV-Control
Host: 172.29.111.1
Host-ID: host-364
VM: server001
Virtual Nics List:
1.
Vnic Name      server001 - Network adapter 1
Vnic Id        5007692e-fc28-ffdb-acd4-964a3a98f2a9.000
Filters
Filter Name    nic-90645-eth0-vmware-sfw.2
Filter Hash    57896

Display Rules

To display the firewalls rules applied to a Vnic we can run the following command. As you can see this displays both the L2 and L3 rule sets.

nsxmgr.packetflow.local> show dfw host host-364 filter nic-90645-eth0-vmware-sfw.2 rules
ruleset domain-c173 {
  # generation number: 1540937748118
  # realization time : 2018-10-30T23:15:22
  rule 1005 at 1 inout protocol icmp icmptype 8 from any to addrset ip-securitygroup-10 accept;
  rule 1005 at 2 inout protocol icmp icmptype 0 from any to addrset ip-securitygroup-10 accept;
  rule 1005 at 3 inout protocol tcp from any to addrset ip-securitygroup-10 port 80 accept;
  rule 1003 at 4 inout protocol ipv6-icmp icmptype 135 from any to any accept;
  rule 1003 at 5 inout protocol ipv6-icmp icmptype 136 from any to any accept;
  rule 1002 at 6 inout protocol udp from any to any port 67 accept;
  rule 1002 at 7 inout protocol udp from any to any port 68 accept;
  rule 1001 at 8 inout protocol any from any to any reject;
}

ruleset domain-c173_L2 {
  # generation number: 1540937748118
  # realization time : 2018-10-30T23:15:22
  rule 1004 at 1 inout ethertype any stateless from any to any accept;
}

Display Address Sets

For rule entries that contain a security group, an address set is built. The address set is simply the network information discovered (shown next) by the logical switch and/or relevant to the objects defined within the group.

Example: You may have selected a given VM within your security group. Therefore the address group will contain the IP of the VM, which it has learnt via its discovery methods.

nsxmgr.packetflow.local> show dfw host host-364 filter nic-90645-eth0-vmware-sfw.2 addrsets
addrset ip-securitygroup-10 {
# generation number: 1540937748118
# realization time : 2018-10-30T23:17:22
ip 192.168.1.2,
ip fe80::250:56ff:fe87:5ec8,
}

Display Discovered IPs

To view the network information discovered against the relevant Filter and, in turn, the information that is passed into the relating security groups, we can perform the following command:

nsxmgr.packetflow.local> show dfw host host-364 filter nic-90645-eth0-vmware-sfw.2 discoveredips
Entries found for nic-90645-eth0-vmware-sfw.2: 2
        [1] vlan = 0  mac = 00:50:56:87:d3:7f  IP = 192.168.1.1 (ARP snooping)
        [2] vlan = 0  mac = 00:50:56:87:d3:7f  IP = fe80::250:56ff:fe87:d37f (ND snooping)

In order to ensure discovery occurs, we must ensure detection is enabled within the Host Preparation section of Network and Security.

Figure 4 - Dectection types.

Note: This is a key point, as failure to correctly enable the detection types, will result in no discovery and in some cases (based on the matching criteria) an empty address set. As a result, you will find the FW rule - incorrectly - not triggering.

Additional Links

https://www.virtually-limitless.com/nsx/nsx-6-2-centralized-cli-distributed-firewall/

References