vrandom yet another random IT blog

Can NSX firewall a VMKernel port?

Overview

Recently I’ve had a few discussions during which statements have been made around NSX’s ability to firewall the VMKernel port of a Hypervisor, using its distributed firewall functionality. So I’m planning on putting this to bed once and for all!

What you’ll need

Fully configured vSphere and NSX environment

Preparation

First here are some hosts I’m going to be utilizing in my lab:

  • lynx - This is an external Linux firewall, I’ll be running external connectivity test from here
alex@lynx:~$ ifconfig eth5
eth5      Link encap:Ethernet  HWaddr 52:54:00:a0:23:8e  
          inet addr:10.30.20.1  Bcast:10.30.20.255  Mask:255.255.255.0
  • dc01 - This is my domain controller, I’ll be running some connectivity test from here dc01 info

  • web01 - This is a Linux VM, I’ll be running some connectivity tests to here web01 info

  • hyp-c01 - This a hyp (shock horror), I’ll be running some connectivity tests to here hyp-c01 info

All devices in this test are located on the lab1-mgmt portgroup: switch location

Confirm existing connectivity

From my firewall device, which is external to the NSX environment:

alex@lynx:~$ #First hyp-c01
alex@lynx:~$ nc -zv 10.30.20.201 22
Connection to 10.30.20.201 22 port [tcp/ssh] succeeded!
alex@lynx:~$ #Now web01
alex@lynx:~$ nc -zv 10.30.20.29 22
Connection to 10.30.20.29 22 port [tcp/ssh] succeeded!

Now the same tests again from a VM within the NSX environemnt: test1

All connectivity test were successful!

Test 1: General Ruleset

Right, so lets create a ruleset based on the IP’s we wish to block: ruleset1 The ruleset is published, and lets check what connectivity remains, first from the external device:

alex@lynx:~$ #First hyp-c01
alex@lynx:~$ nc -zv 10.30.20.201 22
Connection to 10.30.20.201 22 port [tcp/ssh] succeeded!
alex@lynx:~$ #Now web01
alex@lynx:~$ nc -zv 10.30.20.29 22
nc: connect to 10.30.20.29 port 22 (tcp) failed: Connection refused

Now from my VM within the environment: result2

Result:

Fail: The ruleset only blocks communication which originates within the NSX environment.

Test 2: Ethernet Ruleset

After removing the above rule, I then moved on to attempt to replicate this in the Ethernet section. However you can’t opt to block by IP. vNIC only allows VMs (so I’ve picked my web01 test server) so I will utilize a MAC Set, and specify the MAC address of the hyp-c01 VMK:

alex@lynx:~$ arp -n|grep 10.30.20.201
10.30.20.201             ether   d0:bf:9c:45:f9:fc   C                     eth5

mac ruleset2 ruleset2 The ruleset is published, lets check the results from my external device:

alex@lynx:~$ #First hyp-c01
alex@lynx:~$ nc -zv 10.30.20.201 22
Connection to 10.30.20.201 22 port [tcp/ssh] succeeded!
alex@lynx:~$ #Now web01
alex@lynx:~$ nc -zv 10.30.20.29 22
nc: connect to 10.30.20.29 port 22 (tcp) failed: No route to host

And from within the environment: result2

Result:

Fail: Again traffic within the NSX environment is blocked, however traffic from elsewhere on the network is not.

Summary

Luckily I don’t need to eat humble pie, which is always nice! The NSX distributed firewall provides excellent coverage for your virtualized workloads, however where people have witnessed it ‘protecting’ their hypervisor kernel ports, I can only assume they were accessing the environment from a VM protected by NSX (or routing through an Edge) and it was the traffic filtering on these devices which actually limited their access.
Although I used the word fail in my tests above, this is in no way a failing on the part of NSX, and makes perfect sense (to me anyway), when taken with the description of the distributed firewall running on the ‘cable’ between a VM and its virtual switch. So to protect your kernel ports you still need to utilize either the Host Based Firewall[3], Distributed vSwitch IP Filtering[4] or correct protection at the perimeter (which may well be NSX).

Design Guide

The excellent NSX Design Guide[5] provides the below quote, which explains why the above observations occur: > One DFW instance is created per VM vNIC (for instance, if a new VM with 3 vNICs is created, 3 instances of DFW will be allocated to this VM). Configuration of these DFW instances can be identical or completely different based on “apply to” application: when a DFW rule is created, the user can select a Point of Enforcement (PEP) for this rule: options vary from Logical Switch to vNIC. By default “apply to” is not selected meaning the DFW rule is propagated down to all DFW instances.

Which correlates exactly with the operation we have witnessed.

Off topic lesson

Whilst testing this, I did configure the Ethernet ruleset with a TCP Service defined (as below) ethernet service As the port number is not Layer 2, this stops the rule from actually matching any traffic, something to remember for the future! - Be careful what services you specify for your Ethernet rules.

Credits

Thanks to Ricardo for double checking my logic, providing the Design Guide reference and bouncing a few interesting questions backwards and forwards - @canina_pt

References

FIN