FQDN based IP Sets in DFW rules

Using PowerNSX to create FQDN populated IP Sets

NSX for vSphere does not have the ability to create FQDN based rules. Traditionally, a FQDN based rule will use the management planes registered DNS server to perform a lookup against a domain name. This will then return the IP address associated with web page and update an address set. Traditional firewalls such as SRX or ASA have this ability. Thanks to PowerNSX, NSX for vSphere does now as well!

Using the FQDN tool

Lets try on a very common website that most people have visited before.

PS /> ./fqdn-ipset.ps1 -domainname facebook.com

Adding new IPv4 addresses to IPS-facebook.com-v4
Adding new IPv6 addresses to IPS-facebook.com-v6
Tidying IPv4 entries
Tidying IPv6 entries

Alright! Two successfully created IP Sets for Facebook. It includes both IPv4 and IPv6 addresses.

PS /> get-nsxipset IPS-facebook.com-v4

objectId           : ipset-24
objectTypeName     : IPSet
vsmUuid            : 4201B045-B1F9-457F-E621-B54038A6AFA5
nodeId             : 4b749a6a-bc41-431b-bf24-cf9e54dcb452
revision           : 13
type               : type
name               : IPS-facebook.com-v4
description        :
scope              : scope
clientHandle       :
extendedAttributes :
isUniversal        : false
universalRevision  : 0
inheritanceAllowed : false
value              : 

So there is a single IP address in the value property. Great! To prove that it is the current DNS entry lets run the resolution manually.

PS /Users/aburke/Documents/git/nsx-scripts/FQDN-IPset-update> [System.Net.Dns]::GetHostAddressesAsync($domainname).result

AddressFamily      : InterNetwork
ScopeId            :
IsIPv6Multicast    : False
IsIPv6LinkLocal    : False
IsIPv6SiteLocal    : False
IsIPv6Teredo       : False
IsIPv4MappedToIPv6 : False
IPAddressToString  :

AddressFamily      : InterNetworkV6
ScopeId            : 0
IsIPv6Multicast    : False
IsIPv6LinkLocal    : False
IsIPv6SiteLocal    : False
IsIPv6Teredo       : False
IsIPv4MappedToIPv6 : False
IPAddressToString  : 2a03:2880:f126:83:face:b00c::25de 

Great! There is a single entry for IPv4 and IPv6.

Running it again and cleanup

The script is built to handle existing IP Sets. It is also built to remove IP Addresses that are no longer being resolved. Lets run it again to see the behaviour of the script if something already exists.

PS /> ./fqdn-ipset.ps1 -domainname facebook.com

Attempting to add 2 IPv4 address(es) to IPS-facebook.com-v4

WARNING: Value is already a member of the IPSet IPS-facebook.com-v4

Attempting to add 1 IPv6 address(es) to IPS-facebook.com-v6

WARNING: Value 2a03:2880:f126:83:face:b00c::25de is already a member of the IPSet IPS-facebook.com-v6

Tidying IPv4 entries
Tidying IPv6 entries

This example shows a WARNING. This is some smarts built into PowerNSX by Dale and Nick. It will identify if an IP address already exists. If it does and you attempt to add it then PowerNSX will pass a warning to the console. It’s an example of building some smarts over the top of the API.

It will then remove old or stale IP Addresses from the IPv4 and IPv6 IP Sets. This is done by comparing updated IP’s to existing IP’s. Lets have a look at the dataplane to confirm.

[[email protected]:~] vsipioctl getrules -f nic-5454921-eth0-vmware-sfw.2
ruleset domain-c26 {
  # Filter rules
  rule 1012 at 1 inout protocol tcp from addrset ip-securitygroup-26 to addrset dst1012 port 443 accept;
  rule 1012 at 2 inout protocol tcp from addrset ip-securitygroup-26 to addrset dst1012 port 80 accept;
  rule 1003 at 3 inout protocol ipv6-icmp icmptype 135 from any to any accept;
  rule 1003 at 4 inout protocol ipv6-icmp icmptype 136 from any to any accept;
  rule 1002 at 5 inout protocol udp from any to any port 68 accept;
  rule 1002 at 6 inout protocol udp from any to any port 67 accept;
  rule 1001 at 7 inout protocol any from any to any accept;

Now lets have a look at the container on the dataplane which represents the destination addresses.

[[email protected]:~] vsipioctl getaddrsets -f nic-5454921-eth0-vmware-sfw.2
addrset dst1012 {
ip 2a03:2880:f126:83:face:b00c:0:25de,

It’s working and populated with the IPv4 and IPv6 addresses from the previous examples.

Using it in a rule

So now there is a dynamically updated pair of IPsets for IPv4 and IPv6 addresses, what about a rule? Here is an example rule.

Screenshot 2017 07 13 21 45 53

This will allow Virtual Machines associated with the source Security Group access to the destination IP addresses on HTTP/HTTPs.

Keeping it up to date

Name resolution is performed by the local host the script is run on. It will talk to the DNS server it has been assigned. This could be run on a dedicated virtual machine or container. The script can be run as a cron job or scheduled task at an interval of every 5 minutes to ensure resolution is current and up to date. If that is the case the user would need to define a connection to NSX Manager and start a powershell session as well!

This is what the interaction would look like with a ‘script-server’ running the tool.


It would need to talk to the DNS server and NSX Manager. This topoogy is to provide an idea of what connectivity may look like.

The code

The code for this script is found on my GitHub here


It is most likely than an enterprise would use this for internally hosted workloads. These may be virtual IPs for applications or internal hosted services. The frequency of this tool along with the speed of updates is dependant on the rate of changes for addresses.

Custom Regex queries for Log Insight

The missing query

Log Insight provides content packs that come chocked full of queries, alarms, and dashboards for users of specific products. They cover networking, security, storage, hardware, servers and more. A recent update to the NSX for vSphere content back saw TCP Protocol removed. I use TCP protocol heavily in my “segmentation approach” when learning applications. As a result I needed it back. This is where custom queries are useful.

Custom queries

The query missing was searching the dfwpkt log file for the INET protocol (L3 DFW) and then what protocol is used. This is handy in determining what type of rule to build such as UDP or TCP services.

  • Name: vmw_nsx_firewall_protocol
  • pre-context: (IN|OUT) (\d+ )?
  • post-context: \s
  • custom-regex: (TCP6?|UDP6?|PROTO6?\d+)
  • additional-context dfwpktlogs INET

These fields are create in a custom field. This is done by highlighting an the desired field on a given log (TCP in my case). Right click and select Extract Field.


This results in my queries and dashboards working as desired again.


Now I can easily see what is talking to and from my apps when segmenting them. Happy days.

NOTE: This was removed in the NSX Content Pack 3.4 due to it being a resource expensive query. This expensive regex slowed down a query and a any dashboard it referenced and was removed.