NSX-v – Show dfw rules applied to VM
For my example, I’m using a very simple example, with only 3 VMs, connected to the same Logical Switch. They are all sitting on the same Host.
To start of, there are only default rules configured in the dfw, with a any-any-permit rule:
Let’s start with VM “Ubu1-1”. In order to investigate this VM, we need its MoRef ID.
There are multiple ways to get it. I personally prefer PowerCLI:
Get-VM -Name "Ubu1-1" | select name, id | fl Name : ubu1-1 Id : VirtualMachine-vm-764
Alternatively, since we need to login to NSX Manager next anyway, you can also drill down to the VM from there:
nsxv.cloudborn.lab> show cluster all No. Cluster Name Cluster Id Datacenter Name Firewall Status Firewall Fabric Status 1 MGMT domain-c7 DC1 Not Ready UNKNOWN 2 COMP domain-c85 DC1 Enabled GREEN nsxv.cloudborn.lab> nsxv.cloudborn.lab> show cluster domain-c85 Datacenter: DC1 Cluster: COMP No. Host Name Host Id Installation Status Firewall Fabric Status 1 esxi2.cloudborn.lab host-89 Enabled GREEN 2 esxi3.cloudborn.lab host-92 Enabled GREEN 3 esxi4.cloudborn.lab host-95 Enabled GREEN nsxv.cloudborn.lab> nsxv.cloudborn.lab> show host host-89 Datacenter: DC1 Cluster: COMP Host: esxi2.cloudborn.lab No. VM Name VM Id Power Status 1 ubu1-1 vm-764 on 2 ubu1-2 vm-765 on nsxv.cloudborn.lab>
Either way, we see that VM “Ubu1-1” has MoRef-ID “vm-764“
Let’s continue with VM details:
nsxv.cloudborn.lab> show vm vm-764 Datacenter: DC1 Cluster: COMP Host: esxi2.cloudborn.lab Host-ID: host-89 VM: ubu1-1 Virtual Nics List: 1. Vnic Name ubu1-1 - Network adapter 1 Vnic Id 500c72ea-5ea2-5a63-569b-80b259b010f4.000 Filters Filter Name nic-2110847-eth0-vmware-sfw.2 Filter Hash 4785
From here, we need the Filter Name “nic-2110847-eth0-vmware-sfw.2”
Now, we can finally check, which dfw rules are applied to this NIC (Ubu1-1 eth0):
nsxv.cloudborn.lab> show dfw host host-89 filter nic-2110847-eth0-vmware-sfw.2 rules
ruleset domain-c85 {
# generation number: 1565198247068
# realization time : 2019-08-07T18:52:27
rule 1003 at 1 inout protocol ipv6-icmp icmptype 135 from any to any accept;
rule 1003 at 2 inout protocol ipv6-icmp icmptype 136 from any to any accept;
rule 1002 at 3 inout protocol udp from any to any port 67 accept;
rule 1002 at 4 inout protocol udp from any to any port 68 accept;
rule 1001 at 5 inout protocol any from any to any accept;
}
ruleset domain-c85_L2 {
# generation number: 1565198247068
# realization time : 2019-08-07T18:52:27
rule 1004 at 1 inout ethertype any stateless from any to any accept;
}
Lines 5-9 are now showing us, that all rules, we have seen earlier in the GUI, are applied to eth0 on VM “Ubu1-1”. If a specific rule ID appears more than once (like 1003 & 1002 in our example), that means, there are multiple services included in this rule.
Lets configure a new dfw rule, which blocks ICMP from “Ubu1-1” to “Ubu1-2” and apply this rule to “LS1-192.168.1.0-24”.
Since this rule only blocks ICMP Echo from “Ubu1-1” to “Ubu1-2” a ping in opposite direction still works.
Let’s check which rules are now applied to both VMs eth0 interfaces.
VM “Ubu1-1” eth0:
nsxv.cloudborn.lab> show dfw host host-89 filter nic-2110847-eth0-vmware-sfw.2 rules
ruleset domain-c85 {
# generation number: 1565217423197
# realization time : 2019-08-07T22:37:03
rule 1005 at 1 inout protocol icmp icmptype 8 from addrset ip-vm-764 to addrset ip-vm-765 drop;
rule 1003 at 2 inout protocol ipv6-icmp icmptype 135 from any to any accept;
rule 1003 at 3 inout protocol ipv6-icmp icmptype 136 from any to any accept;
rule 1002 at 4 inout protocol udp from any to any port 67 accept;
rule 1002 at 5 inout protocol udp from any to any port 68 accept;
rule 1001 at 6 inout protocol any from any to any accept;
}
VM “Ubu1-2” eth0:
nsxv.cloudborn.lab> show dfw host host-89 filter nic-2209772-eth0-vmware-sfw.2 rules
ruleset domain-c85 {
# generation number: 1565217423197
# realization time : 2019-08-07T22:42:16
rule 1005 at 1 inout protocol icmp icmptype 8 from addrset ip-vm-764 to addrset ip-vm-765 drop;
rule 1003 at 2 inout protocol ipv6-icmp icmptype 135 from any to any accept;
rule 1003 at 3 inout protocol ipv6-icmp icmptype 136 from any to any accept;
rule 1002 at 4 inout protocol udp from any to any port 67 accept;
rule 1002 at 5 inout protocol udp from any to any port 68 accept;
rule 1001 at 6 inout protocol any from any to any accept;
}
We can see, that rule 1005 is applied to both VMs eth0 interfaces.
Note: Because I’ve selected the Logical Switch in the “Applied To” field for the rule, this rule is also applied to VM “Ubu1-2” eth0 too, even though it will never get hit by this VM. In our example, this is nothing to worry about. But if you think about enterprise environments with thousands of rules, this can potentially lead to issues. Especially, if you leave the “Applied To” field untouched, by default, the rule will be added to all VMs vNICs, managed by this distributed firewall. This will eventually lead to a situation where new rules are not properly applied to the VMs, or even worse, the host become unresponsive because it can’t handle the amount of rules anymore.
According to the NSX-v 6.4.5 Configuration Maximums, a single vNIC can have 3.500 rules attached to it. And a single Host can handle up to 10.000 rules ( –> VMware Configuration Maximums ).
At first glance, this seems to be a lot, but if you think about how many rules you need for standard services (dns, ntp, ldap,…) and now multiply them by the amount of VMs per host and maybe even multiply this by the amount of vNICs …
