When using the VMware NSX Distributed firewall, it’s common to use vRealize Log Insight for firewall rule analyses but there is a little problem with it, which I will try to explain and resolve.
The great thing about the VMware NSX Distributed Firewall is that you can assign vSphere objects directly to the firewall rules. VMware NSX takes care of the translation of these objects to IP addresses, which are automatically programmed at the vNIC level of each Virtual Machine. This enables application-based firewalling instead of having to keep your IP address(-objects) in sync with the environment manually.
All is good until this point!
But when your are implementing rules you have to rely on the captured logs to adjust the firewall rules.
The produced logs look something like this:
2020-04-01T15:01:06.374Z esx01.vviking.local dfwpktlogs: 60247 INET match PASS domain-c08/1001 IN 52 TCP 192.168.1.1/62180->192.168.1.54/443 S These are not vSphere objects, these are traditional IP addresses .. grmbl. VMware vRealize Log Insight does not translate these IP addresses: You have to translate these IP addresses to vSphere objects yourself.
To solve this problem I created a self-sustained PowerShell module which interacts with the VMware vRealize Log Insight and VMware vSphere API’s. It can retrieve the Log Insight events directly and translates them automatically to vSphere objects.
The module can be found here!
It offers 4 cmdlets:
- Connect-LogInsightServer
- Disconnect-LogInsightServer
- Get-LoginsightNSXEvents
- Enum-PSLoginsightevent
The first two (2) cmdlets are self-explaining and do not need any attention.
The magic is within the last two (2) cmdlets:
Get-LoginsightNSXEvents retrieves all the NSX related events from VMware vRealize Log Insight and returns all the events in a PowerShell hashtable based in the dynamic field extraction capabilities. Which is just #epic #awesome #mindblown
Enum-PSLoginsightevent translates the retrieved PowerShell hashtable output of the Get-LoginsightNSXEvents cmdlet to Virtual Machines and/or DNS hostnames in a very fast way: It can translate 1000 log events in approx. 8 seconds. It also retrieves the Security Group memberships of the Virtual Machines, so you can quickly identify why your firewall rules isn’t working correctly.
It will output again a PowerShell hashtable, but now with the hostnames, DNS hostnames and Security Groups added.
Some of the enhancements, explained:
I had to enhance the scripts multiple times to lower the enumeration time.
Retrieve VM objects faster
For the retrieval of VM objects I always used the following command:
GET-VM
It does it’s job, but very slowly when you have a large amount of Virtual Machines. To enhance my script, I’m using the following cmdlet to retrieve the VM-information:
Get-View -ViewType "VirtualMachine"
This command retrieves the information much faster (up to 3x faster)!
Retrieve VM guest IP addresses
Another enhancements is the retrieval of the VM Guest IP addresses through the VMware Tools. The standard way of retrieving the IP address is:
(Get-VM -Name MyVM).Guest.IPAddress
This command is slow if you have to enumerate a lot of VM’s. I’ve found a quicker command:
$VmObject = (Get-View -ViewType "VirtualMachine").where({$_.name -match "VmName"})
$VMIpAddress = $VmObject.guest.Net.ipconfig.IpAddress.ipaddressÂ
The first command is actively looking up the IP address from the VM, the second (enhanced) script retrieves the data directly from the vCenter database. When using a large amount of VM’s the second script is exponentially faster).
Using the .where method instead of the Where-Object cmdlet.
The next one out, I founded it out the hard way.
Powershell offers the ability to do where operations in two (2) ways.
One through the use of a cmdlet, for example:
$VMobjects | Where-Object {$_.Name -eq "VMname"}
And another is through the use of a cmdlet, for example:
$VMobjects.where({$_.Name -eq "VMname"})
They two almost look like the same, but the timing is the difference! When enumerating a large hashtable or array, the second one is much faster.
