Can NSX firewall a VMKernel port?01 May 2015
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
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
web01 - This is a Linux VM, I’ll be running some connectivity tests to here
hyp-c01 - This a hyp (shock horror), I’ll be running some connectivity tests to here
All devices in this test are located on the lab1-mgmt portgroup:
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:
All connectivity test were successful!
Test 1: General Ruleset
Right, so lets create a ruleset based on the IP’s we wish to block: 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:
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
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:
Fail: Again traffic within the NSX environment is blocked, however traffic from elsewhere on the network is not.
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, Distributed vSwitch IP Filtering or correct protection at the perimeter (which may well be NSX).
The excellent NSX Design Guide 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) 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.
Thanks to Ricardo for double checking my logic, providing the Design Guide reference and bouncing a few interesting questions backwards and forwards - @canina_pt
- NSX Documentation
- NSX Rule Docs
- 3* Host Based Firewall
- 4* dvSwitch IP Filtering
- 5* NSX Network Virtualization Design Guide