NSX Identity Firewall – Deep Dive


One of the major challenges in the modern datacenter is to constantly improving our overall security implementation. In traditional firewalls, we’re building our policy rules based on the famous 5-tuple (Source IP, Source Port, Destination IP, Destination Port, Protocol) to match a specific flow.

It was a very good start for our first generation of the statefull firewalls, but centrality not enough to achieve better security in rapidly dynamic environments, where different users from different roles need to access our applications reside within the datacenter.

Today users are connecting to business applications from various locations such as: internal campus LAN, VDI or via VPN. The user could be a corporate employee or even an external contractor. In some cases, the same user can login from different computers on different locations inside the same company campus. In this growing scenario – is there any meaning for the user’s IP address anymore?

IT Departments needs to provide the same user experience for their customer regardless of the location/device that the end user is connecting from.  With NSX Identity firewall we can simplify the firewall rules and create simpler rule to allow a specific user/group to access an application. This is much easier than creating complex rules with different source IP address reflecting the location the user connects from.

Example of an identity firewall policy:


Another concern is related to the security auditing of user activity inside the datacenter. One of the IT challenges is to investigate cybercrime events, the traditional firewall will have logs and events of the IP address transverse the organization firewall. But after we get suspicious IP, IT will need to understand who is the employee behind this IP (assuming that the attack was from within our network) we can eliminate this step by creating NSX Identity firewall that will record any user activity/access in the datacenter.

Starting from NSX-v 6.0 VMware have the ability to create firewall rules based on the identity of the user defined in the enterprise Active Directory– IDFW (Identity Firewall). In this blog post we will cover in deep dive all the aspects of this technology.

NSX Identity Firewall Usecases:

Access from physical PCs (Log Scrub):

In this usecase we would like to provide access for an employee or an external contractor to our datacenter (shown on the right side) directly from their physical laptop windows PCs or mobile devices without any agent installed on the physical PC. When the user is logged in to a windows domain machine with their Active Directory credentials, successful logon event will be generated inside the Active Directory. With NSX IDFW Log Scrub we’re relying on this event to detect the identity of the user and correlating the IP address. This method named Log Scrub because the NSX manager will need to scrub the logs from the AD to correlate the user ID and IP address to NSX Security Policy.

The firewall policy will be defined based on a user membership or groups membership in the Active Directory. The NSX firewall enforcement will be done at the datacenter’s workloads (on the right side).


Guest Introspection:

In this scenario, the users (from the left side of the figure) will need to access first hop VDI- Virtualized Desktop Infrastructure or any vSphere VMs protected by NSX distributed firewall (shown in the middle of the figure below), and then they will get access to the datacenter workloads (on the right).  The NSX firewall enforcement will be done at the VM level.


As you can see these are two different methods to achieve the same goal of Identity NSX firewall. Design considerations and compressions between the two methods will be explained later.

Now let’s start to explain how its actually works.

High Level Architecture Log Scrub:

In this scenario, users are accessing applications from physical domain-member devices like laptop or PC. With this solution, we are relying on Microsoft successful logon events generated at the AD. From this log event we can learn the identity of a user that just logged in and the IP address of the device that the user came from. Then, based on the firewall policy defined for the AD groups we can control the traffic enforcement at our virtual machines.


The following steps describe this process:

 (1) The user is performing a login to a PC or laptop that are members of the corporate domain.

(2) Successful logon event is generated by the Active Directory.

(3) NSX Manager periodically (Every 5 sec) reads the AD event logs (Log scrub process).

(4) NSX Manager pairs the event logs and users defined at the security policy. The NSX Manager will store the user id and the IP address at the database.

The NSX manager will then translate the Security Group to machines and use what it learned to determine where the firewall policy need to be applied.

(5) NSX will push the firewall policy to related VM in the relevant security group.

(6) The user can now access from a physical PC/laptop a VM inside the datacenter and have the access and policy he/she was allowed.

Guest Introspection High Level Architecture

In the figure bellow I will describe the process to show how NSX Identity Firewall is performing Guest Introspection. With Guest Introspection, we are relying on thin agent installed on the Guest OS machines.  This thin Agent detects the logon user Id and his IP address and report this information to the NSX manager. We’re using VDI or the VMs as a “jump server” before the user can access the destination application located on the Datacenter (shown on the right icon and running as a VM or a bear metal server).

The enforcement point of the NSX firewall will is at the VM or VDI level.

The Virtual Access deployment Guest Introspection (GI) will be explained into details on this blog.


Here is the high level of flow of the user access process:

(1) User login to a Virtual Machine (The VM can be part of Virtual Desktop Infrastructure-  VDI) with AD credentials.

(2) On each VM the thin agent (This is VMTools with Guest Introspection installed) running inside the guest os, detects the login event and update the Service Virtual Machine (SVM) with a user id and IP address combination.

(3) The SVM update the NSX manager with these details user details plus AD Group Memberships.

(4) The NSX Manager will store the user id and the IP address inside its database. \

NSX manager will then translate the Security Group to VMs and understand where the NSX firewall policy needs to be pushed.

(5) NSX will push the firewall policy to the related VM in the relevant security group.

(6) The user will be able to access the application inside the datacenter from his VM.

NSX Guest Introspection:

Guest Introspection (previously called “Endpoint Security” – EPsec) allows NSX deep inspection at the guest OS without installing any 3rd-Party agents.


Guest Introspection allows the following security features:

  1. NSX Identity Firewall.
  2. NSX Activity Monitor.
  3. NSX Data Security.
  4. Agentless Anti-Virus 3rd-Party.
  5. File Integrity 3rd-Party.

At this blog post we will focus on the NSX Identity Firewall.


The Guest Introspection consists of three major components:

Thin Agent:

Inside the Virtual Machine Guest OS we need to install Thin Agent (This is actually just an add-on to the existing VMTools drivers) – known as network introspection. This agent will communicate with the “MUX” via Virtual Machine Communication Interface (VMCI) Channel.

MUX Module:

When we enable Guest Introspection on the cluster level, NSX will install a new VIB (vSphere Installed Bundle) on each ESXi host in our cluster. The new VIB is called “epsec-mux” and MUX module acts as a Multiplexer accepting messages from the Thin Agent running in the VM via VMCI channel, then delivers the information to the SVM (Service Virtual Machine) via a TCP session.

All of the Internal TCP communication of the MUX to SVM is done via PIPA IP address 169.254.1.X over ports 48651-48666.

As a part of Guest Introspection deployment, a new standard switch called “mservice-vswitch” is created at each host, and a new port group named “vmservice-vswitch” will be used for the communication.

Service Virtual Machine – SVM:

On each host in the cluster that we’ve enabled “Guest Introspection” on, NSX will deploy a Service Virtual Machine (SVM).  The SVM will offload the activity needs to be done inside the VM Guest OS and communicate with NSX Manager to send updates and to get new configurations. The SVM have two interfaces: one interface is connected to the standard vSwitch for the MUX traffic, and the Second interface to the management IP defined by the admin to enable the communication to the NSX manager. This communication is done via vDS.


Enable NSX Identity Firewall

Log Scrub – Physical Access

We need to configure NSX manager to read AD groups Security Events Logs.

We can use the same user or different user for the integration with AD.

The First Step to enable Log Scrub is the connect the NSX to the AD.

Click on the NSX Manager icon, then click on his IP Address, in this example it’s  Click on Manage -> Domains -> Click on the Green + icon to add a Domain:


In the figure bellow we need to define a standard domain user in order to have the ability to read the AD schema of users and Groups. With this information, we can later define the NSX firewall policy based on these AD objects.


In this example, we will use the “nsxread” user name. this user Is defined in the AD as just a regular “Domain Users” member without any special permission.


A user with permissions to read the logon/logoff events should be used for this section.The permission requirement is depended on the OS the AD that are running. The protocol used to read this information can be CIFS or WMI.


Depending on the Guest OS the AD running we need to have different permissions for the user we are using to read the Security Log Access from the AD.

Windows 2008 or later domain servers:

The user defined to read the security event logs in Windows 2008 must be member off “Event Log Readers” group. If we are using the on-device User-ID agent, the account must also be a member of the “Distributed COM” Users Group.

In the figure bellow we can see a “nsxlog” user defined in AD 2008 server, as you can see the user is a member of “Event Log Readers”:


Windows 2003 domain servers:

Assign Manage Auditing and Security Logs permissions through group policy.


Event Logs ID:

During the log scrub process the NSX manager will collect the following Microsoft event IDs:

For windows 2008/2012 – Event ID: 4624

For Windows 2003 – Event ID: 540

After defining the LDAP Options and the Security Logs Access we need to simply click finish.


Creating Security Groups:

Before creating the NSX security policy defined with AD groups, we need to create NSX Security Groups and reference this Security Group in the NSX policy.

For Example, we will create SG for Sales group:


To choose the AD group we need to change the Object Type to “Directory Group” and then select one of the AD groups. In this example, we chose AD-Sales:


Now we can create the NSX DFW Policy. The source object in this rule is the AD-Sales Security Group:


Now users that are members of the sales AD group can login to their physical machine and access the “Internal Services” application defined in this NSX policy rule via HTTPS.

Enable IDFW With Guest Introspection:

The IDFW can work with Guest Introspection, there are few steps needs to be done in order to enable Guest Introspection.

Install the Guest Introspection service.

In the NSX interface go to: Installation -> Service Deployment. Click on the Green button and select Guest Introspection as shown in this example:


Select the Cluster you want to enable  Guest Introspection on:


Now we need to configure the Datastore where the SVM will be deployed, the portgroup that will be used for the communication with the NSX manager after the deployment and the IP address assignment for management. Then Click Next -> Finish


After a few minutes, NSX Manager will deploy one SVM per ESXi host in the cluster we chose. The footprint of this SVM is very small: 2 vCPU and 1G RAM per SVM.


In this example, we have only one ESXi host name esx-03a.corp.local in Regin01-COMP02 Cluster, so we have only Guest Introspection SVM:


On each SVM we have 2 vNIC with two IP address.

The first vNIC is VM-RegionA01-vDS-COM (Connected to vDS) and is used for communication with the NSX manager. The Second vNIC “vmservice-vshield-pg” is connected to a standard virtual switch.

The Management IP of this SVM is (This IP was given us by a DHCP as part of the installation of Guest introspection in the cluster). The Second IP was created automatically as part of the SVM deployment and used for communication between the SVM and the MUX process running inside the ESXi host.


After the deployment of the Guest Introspection we need to connect the NSX manager to the AD in order to be able to read the AD schema of user and groups, but we don’t need to read the AD security events logs !!!

The process of the integration with the AD is the same as describe in the Log Scrub chapter except for this, Mark  the “No” in this question:


Design Consideration:

We have explained two different methods to configure IDFW with NSX.

You can now ask: what method is better?  the quick answer; it depends! 🙂

It depends on the scenario of the customer and the environment, these will determine the right approach.

Here is a small compression I’ve created of the two method:



Special thanks  to Daniel Bakshi that help me a lots to review this blog post.

NSX Service Composer: Methodology Concept


Recently in one of my NSX projects I was asked by the customer to develop flexible yet simple to use Security methodology of working with NSX service composer.

The focus was to build the right construct of security groups and security policy based on following requirements:

  • The customer owns different environment types: Dev, Pre-Prod and Prod, Each environment required different security policy.
  • Customer would like to avoid creating specific blocking rules between the environments, such deny rules will cause operation complexity. Security policy should be based on specific allowing rules while all others traffic will be blocked in the last cleanup rule.
  • Minimizing the human error of connecting workload to the wrong security group, which may result in giving it an unwanted access. For example connecting Prod workload to Dev security group.
  • The customer would like to protect 3-tier applications (Web, App and DB), these applications run on 3 vSphere clusters (Dev, Pre-Prod and Prod) .


To achieve the customer requirements, we will build a security concept that is based on the NSX Service Composer.

We will demonstrate the implementation of security policies and security groups to protect 3-tier applications, based on the assumption that the application run on pre-prod cluster but the same concept applies to any cluster.


Security Level Concept:

We will use the concept of “Security Levels” to differentiate between firewall rules granularly.

Each level will have different firewall access policy starting from zero (no access) till the highest level (Application access).

Level-1 Basic Security groups (SG)

Level 1 (L1) SG used to create the building block for the firewall rules, we are not using any security policy directly with Level 1 security groups.

The following security groups created at Level 1:

Cluster SG

Cluster Security Group represents different vSphere clusters.

In our example: Dev, Pre-Prod and Prod. (Some customers may have only two clusters (Dev and Prod) or a similar scenario.

For each vSphere cluster we will have a dedicated security group. Any deployed VM will be included automatically and dynamically in the relevant Cluster security group.

For example: any VM from Pre-Prod cluster will be included in “SG-L1-CL-Pre-Prod” security group.


By creating this dynamic criteria, we have eliminated the need for manual human action.

We can leverage this ability further and create Security policy levels on top on this one.

By doing that we are reducing the human error factor of connecting Virtual Machines to the wrong security groups and as a result enabling them with dangerous unwanted security access.

In Level-1 SG, the machines are member only in a cluster security group representing its vSphere cluster environment and it will not get any dFW rules at this level.

Environment Security Group

This Security Group represents the environment that the machine belongs to.

For example: We might have a different Prod env for IT, R&D, and Sales.

This is very useful when we want to say that a machine is “Prod” and running in “R&D” env rather than “Sales”.

Env-L1 could represent different departments or projects in the company according to the way you build your infrastructure.

For example we will create a security group called “SG-L1-EN-R&D” to represent any machine owned by R&D.

The membership criteria in this example is security tag called “L1-ST-ENV-R&D”.


Application Security Group

The Application Security Group comes to indicate the application installed on the machine (For example: Web, App or DB).

Virtual Machines will be assigned to this group by NSX security tag.

An example of security group name “SG-L1-Web” with match criteria security tag called


The full list of level 1 security tag shown in image bellow:


Level 1 Security Groups Building Blocks Concept:

Level 1 Security Groups Building Blocks Concept

Level 2 Infrastructure Security Group

Infrastructure rules are used by machines to get common System Services like: Active directory, DNS, Anti virus and different agents and services that manage the environment.

Combining both L1-Cluster and L1-Env security groups (with Logical “AND”) will form the “Infrastructure” security group shown as Level-2 that allow the Virtual Machines to get infrastructure security policy based on the VM role.

For example, we will create Level 2 Security group called “SG-L2-INF -R&D“, this SG represent Virtual Machines from the SG-L1-CL-Pre-Pre SG  AND belong to SG-L1-EN-R&D SG environment.

The match criteria are security groups, we called this nested security groups.


The Result of adding Level 2 security on-top of Level 1 security is illustrated in the following diagram:

Level 2 security


Level 3 Application Security Group

Level-3 security group are used for application access level. Security groups in this level are combining a level-2 infrastructure SG AND a level 1 application SG.

For example, we will create the security group “SG-L3-Pre-Pro-WEB” with dynamic membership criteria matching of L1 Security group “SG-L1-WEB” and security group “SG-L2-INF-R&D”:


The relation between the different security groups is illustrated in the next diagram:

Level 3

For example, web VM from the web tier. This VM was deployed to Pre-Prod cluster, as results this VM automaticity belong to “SG-L1-CL-Pre-Prod.

The VM got the NSX security tag called “L1-ST-EN-Pre-Prod” and as result it will be a member of security group called “SG-L1-EN-Pre-Prod”.

The VM was attached with the NSX security tag “L1-ST-APP-Web” and is now a member of security group called “SG-L1-APP-WEB”.

Because of the membership in both security groups: “SG-L1-EN-Pre-Prod” AND “SG-L1-APP-WEB” this VM is automatically a member of security group called “SG-L2-EN-Pre-Prod”.

As a result of the VM being a member of “SG-L2-EN-Pre-Prod” and “SG-L1-AP-WEB” it will automatically be member of “SG”L3-Pre-Prod-APP-WEB”

Please note we’re demonstrating here just the WEB tier what the same concept Apply to APP and DB tier.

Service Composer Security Policy

Security policy for L2 infrastructure workloads in service composer includes generic firewall rules to enable workloads with infrastructure system connectivity like DNS,AD, Anti-Virus etc..

For example Level 2 security policy named as “L2-SP-INF-R&D” and contain example of 4 firewall rules:


then we’ll apply the “L2-SP-INF-R&D” security policy on the “SG-L2-INF-R&D” security group.

Service Composer Application Security Policy

Security policy for Application workloads in service Composer includes firewall policy for application. For example, the web tier security policy called “SG-L3-R&D-WEB” and contains one firewall rule:


Then we will apply the “L3-SP-R&D-WEB” to security policy on the “SG-L3-R&D-WEB” security group.

Example for security policy to allow the Web tier to talk to App tier with Tomcat service:


Then we’ll apply the “L3-SP-R&D-APP” security policy on the “SG-L3-R&D- APP” security group.

Example for security policy to allow App tier to talk to DB tier with MySQL:


Then we will apply the “L3-SP-R&D-DB” to security policy on the “SG-L3-R&D-DB” security group.

Starting from NSX version 6.2.x we can enable the “Apply To” feature to automatically enforce security policy on the security group object instead of the default distributed firewall (means apply the policy anywhere).

This is a great feature that help us avoid “spamming” of objects with unrelated dFW rules so we are more efficient with our system.

To enable this feature we need to use the following steps. In Service Composer click on “Edit Policy Firewall Setting”


Then choose the checkbox the “Policy Security Group” instead of “Distributed Firewall”.


We can view the full service composer firewall result in the “Firewall” Tab:


To demonstrate the effective security policy combined with the different security levels let’s look at ‘Monitor -> service Composer’ at a VM object level.

Here is screenshot of Web-02a VM part of the WEB tier:


The effective security policy for web-02a can be verified under Monitor -> Service Composer tab in the web client:


The effective security policy for App-02a can be shown in the Monitor -> Service Composer tab:


The effective security policy for DB-02a can be shown in the Monitor -> Service Composer tab:


To recap the complete Security Group list:


The complete Security Policy list:


I would like to Thanks to Daniel Bakshi that review this blog post.


Reference blogs post by my colleagues:

Sean Howard wrote great blog post with service composer concept:


Anthony Burke also Cover the Service Composer subject :


And from  Service Composer on VMware official wrote by Romain Decker 


NSX Distributed Firewall Deep Dive

The following topics will be covered by this NSX DFW Deep dive:

NSX Distributed Firewall Overview:

NSX DFW is an distributed firewall spread over ESXi host and enforced as close to source of the VMs traffic (shown in each VM). The DFW runs as a kernel service inside the ESXi host.

With the NSX DFW we can enforce a stateful firewall service for VMs and the enforcement point will be at the VM virtual NICvNIC. Every packet that leaves the VM (before VTEP encapsulation) or enters the VM (After VTEP deencapsulation) can be inspected with a firewall policy.


The DFW runs inside the ESXi host as a kernel space module, resulting in an impressive throughput.

What makes the DFW an amazing feature is that as we add more ESXi host to vSphere cluster we increase the DFW throughput capacity.

The DFW rules can be based on Layer 2 up to Layer 4 and with 3-Party vendor integration the NSX can implement security features up and including L7.

  • L2 rules are based on MAC address L2 protocols like ARP, RARP and LLDP etc.
  • L3 rules are based on IP source destination and L4 uses a TCP or UDP service port.

The policy is created in centralized point at the vSphere vCenter server using vCenter web client. The objects used are being used from the vCenter inventory.

How NSX Distributed Firewall work:

 This section take from amazing NSX Design guide:

The DFW instance on an ESXi host (1 instance per VM vNIC) contains 2 separate tables:

Rule table: used to store all policy rules.

Connection tracker table: cache flow entries for rules with permit action.

Note: a specific flow is identified by the 5-tuple information Source IP address/Destination IP address/protocols/L4 source port/L4 destination port. Notice that by default, DFW does not perform a lookup on L4 source port, but it can be configured to do so by defining a specific policy rule.

Before exploring the use case for these 2 tables, let’s first understand how DFW rules are enforced:

DFW rules are enforced in top-to-bottom ordering. Each packet is checked against the top rule in the rule table before moving down the subsequent rules in the table. The first rule in the table that matches the traffic parameters is enforced Because of this behavior, when writing DFW rules, it is always recommended to put the most granular policies at the top of the rule table. This is the best way to ensure they will be enforced before any other rule.

DFW default policy rule (the one at the bottom of the rule table) is a “catch-all” rule: packet not matching any rule above the default rule will be enforced by the default rule. After the host preparation operation, the DFW default rule is set to ‘allow’ action. The main reason is because VMware does not want to break any VM to VM communication during staging or migration phases. However, it is a best practice to change the default rule to ‘block’ action and enforce access controls through a positive control model (only traffic defined in the firewall policy is allowed onto the network).

Let’s now have a look at policy rule lookup and packet flow:

An IP packet (first packet – pkt1) that matches Rule number 2 is sent by the VM. The order of operation is the following: Lookup is performed in the connection tracker table to check if an entry for the flow already exists.

As Flow 3 is not present in the connection tracker table (i.e miss result), a lookup is performed in the rule table to identify which rule is applicable to Flow 3. The first rule that match the flow will be enforced.

Rule 2 matches for Flow 3. Action is set to ‘Allow’.

Because action is set to ‘Allow’ for Flow 3, a new entry will be created inside the connection tracker table. The packet is then transmitted properly out of DFW.




DFW policy rule lookup and packet – subsequent packets.

Subsequent packets are processed in this order:

Lookup is performed in the connection tracker table to check if an entry for the flow already exists.

An entry for Flow 3 exists in the connection tracker table => Packet is transmitted properly out of DFW

One important aspect to emphasize is that DFW fully supports vMotion (automatic vMotion with DRS or manual vMotion). The rule table and the connection tracker table always follow the VM during vMotion operation. The positive result is there is no traffic disruption during workload moves and connections initiated before vMotion remain intact after the vMotion is completed. DFW brings VM movement freedom while ensuring continuous network traffic protection.

Note: this functionality is not dependent of Controllers or NSX Manager being up and available.

NSX DFW brings a paradigm shift that was not possible before: security services are no longer dependent on the network topology. With DFW, security is completely decoupled from logical network topology.

In legacy environments, to provide security services to a server or set of servers, traffic from/to these servers must be redirected to a firewall using VLAN stitching method or L3 routing operations: traffic must go through this dedicated firewall in order to protect network traffic.

With NSX DFW, this is no longer needed as the firewall function is brought directly to the VM. Any traffic sent or received by this VM is systematically processed by the DFW. As a result, traffic protection between VMs (workload to workload) can be enforced if VMs are located on same Logical Switch (or VDS VLAN-backed port-group) or on different Logical switches.


NSX DFW architecture:

The vCenter, NSX Manager and ESXi host are functioning as the 3 main components in this architecture.

DFW Architecture

DFW Architecture

NSX Manager: The NSX manager provides the single point of configuration and the REST API entry-points in a vSphere environment for NSX. The consumption of NSX can be driven directly via the NSX manager UI. In a vSphere environment this is available via the vSphere Web UI itself. Typically end-users tie in the network virtualization to their cloud management platform for deploying applications.

vCenter: VMware vCenter Server provides a centralized platform for managing your VMware vSphere environments so you can automate and deliver a virtual infrastructure with confidence.

ESXi host: VMware ESXi is the hypervisor running the virtual machines guest OS. DFW related modules:

  1. vShiled-Statefull-Firewal service daemon run in the user space
  2. vSIP run in the kernel space.

vShiled-Statefull-Firewal: Service demon Runs constantly on the ESXi host and performs multiple tasks:

  1. Interact with NSX Manager to retrieve DFW policy rules.
  2. Gather DFW statistics information and send them to the NSX Manager.
  3. Send audit logs information to the NSX Manager.
  4. Receive configuration from NSX manager to create (or delete) DLR Control VM, create (or delete) ESG.
  5. Part of the host preparation process SSL related tasks from NSX manager


Message Bus Client: The NSX Manager communicates with the ESXi host using a secure protocol called AMQP.

Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware. The defining features of AMQP are message orientation, queuing, routing (including point-to-point and publish-and-subscribe), reliability and security”

Source: http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol.

RabbitMQ is the NSX AMQP implementation.

The vShiled-Statefull-Firewal is acting as a RabbitMQ Client in the ESXi. The vShiled-Statefull-Firewal is a user space service daemon and uses a TCP/5671 connection to the RabbitMQ server in the NSX manager. The message bus is used by the NSX Manager to send various information’s to the ESXi hosts:

Policy rules for the DFW module, controller nodes IP addresses, private key and host certificate to authenticate the communication between host and controller and requests to create/delete DLR instances.

vSIP: VMware Internetworking Service Insertion Platform. This is the distributed firewall kernel space module core component. The vSIP receives firewall rules from NSX manager (through vShiled-Statefull-Firewal) and downloads them down to each VM VMware-sfw.
Note: VMware Internetworking Service-Insertion Platform is also a framework that provides the ability to dynamically introduce 3rd party and VMware’s own virtual as well as physical security and networking services into VMware virtual network.

VPXA: A vCenter agent, installed on the ESXi host when the vCenter communicates with the ESXi host for first time. With the VPXA the vCenter manage the ESXi host for vSphere related tasks. Although it is not a direct part of the DFW architecture the VPXA is being used to report the VM IP address with VMtools. 


IOChains: VMware have a reserved IOchains handle packet process at the Kernel level.

Slot 0: DVFilter (Distributed Virtual Filter):

Distributed Virtual Filter DVFilteris is the VMkernel between the protected vNIC at SLOT 0 associated Distributed Virtual Switch (DVS) port, and is instantiated when a virtual machine with a protected virtual NIC gets created. It monitors the incoming and outgoing traffic on the protected virtual NIC and performs stateless filtering.

Slot 1: sw-sec (Switch Security): sw-sec module learns VMs IP and MAC address. sw-sec is critical component capture DHCP Ack and ARP broadcast message and forward this info as unicast to NSX Controller to perform the ARP suppression feature. sw-sec is the layer where NSX IP spoofgurd is implemented,


Slot-2: VMware-sfw: This is the place where DFW firewall rules are stored and enforced, VMware-sfw contains rules table and connections table.

NSX policy push process:

We create a security policy with vCenter GUI, this configuration then stored inside NSX manager. When we push the policy NSX Manager Will sends firewall rules in protobuf format to all vSphere clusters.

Protocol Buffers are a method of serializing structured data. As such, they are useful in developing programs to communicate with each other over a wire or for storing data. The method involves an interface description language that describes the structure of some data and a program that generates from that description source code in various programming languages for generating or parsing a stream of bytes that represents the structured data.

Source: http://en.wikipedia.org/wiki/Protocol_Buffers

All ESXi host part from vCenter cluster will receive this policy with vShiled-Statefull-Firewal daemon over the message bus.At this point vShiled-Statefull-Firewal need to parse this rules and convert them from protobuf messages into the vmkernel vSIPIOCTL format, then vSIP will apply the rules on every VMs SLOT 2 VMware-sfw.

Note: This process flow describe “Applied To” filed in security policy is “Distributed Firewall” = rule applied everywhere.

A security administrator can create firewall rules built from vCenter objects like:

Cluster, DC, VDS port-group, Logical Switch, IPSets, Resource Pool, vAPP, VM, vNIC and Security Groups. The NSX firewall enforce point at the VMware-sfw can only understand IP address or MAC address.

In figure shows below we create a firewall rule to allow ICMP Source “Compute Cluster A to Destination “Compute Cluster B”:

Policy push process

Policy push process

The NSX Manager will need to figure out what are the object IDs represented by “Compute Cluster A” and “Compute Cluster B” and then reveal what the IP address correspond to those VMs.

The NSX firewall rules inside ESXi host are created as VSIPIOCTL format and then applied on the VMware-sfw.

The NSX manager relies on the vCenter internal database to get object-ID/IP address mapping, we can view the data with the vCenter MOB (Managed Object Browser) Using this url: https://vCenter_IP/mob/

The NSX manager keeps this info inside his internal database.

The vCenter server represents any object with a unique id. For example “Compute Cluster A” in fact equals to domain-c25 and “Compute Cluster B” equal to domain-c26. Here is screenshots from vCenter MOB:


 NSX DFW and VMtools:

The NSX (up to current version 6.1.3) relies on the VMtools to learn the IP address of the Guest OS. The IP address learned from the VMtools is stored in the vCenter database and reported to NSX manager. We can tell if VMtools reports the IP address in VM Summery screen:


To view the vm-id we can be retrieve using vCenter at the following path:
https://<vCenter server>/mob and select content -> rootFolder -> childEntity -> vmFolder.


To view the VMs IP address go to click on the vm-id from the list above, for example vm-36 (web-sv-01a).

     GuestInfo -> Net

In vCenter MOB “web-sv-01a” has Object ID: vm-36 with IP address “”.


If the VMTools was stopped or removed the vCenter removes the IP address entry immediately. An update notification will send to NSX manager cause to firewall module send a list updates to all the vShiled-Statefull-Firewal processes using protobuf format. If we configure firewall rules using vCenter objects (not IP address) as show in screenshot below, there will be a match on the last firewall rule (most of the time called catch-all rule).


If this rule configure to block (as in this example) then this VM will be blocked from the network, but if this rules send the permit then the VM gets a full network access, which allows the user to bypass security policy.

Spoofguard: NSX feature that we can use to eliminate the need of VMtools to learn the VM IP address but this will be address in a different blog post.



 NSX Firewall and vMotion:

vMotion: enables to move a VM from one ESXi host to another while this VM is powered on and connected to network in vSphere environment.

This feature can be managed automatic by the vSphere DRS mechanism or manually by the vSphere administrator.

As we saw in the NSX DFW architecture for each VM we have two separate tables:

DFW table: Contains the firewall rules.

DFW Connection table: Contains the live active (approved) connection passing through this VM. When VM1 vMotion process starts these two tables will follow the VM1 movement over the vMotion link.

NSX dFW vMotion

NSX dFW vMotion

When the vMotion process completes the VM1 will land at esxcomp-01b and have same firewall rules and same connection table and as a result there’s no traffic disruption for VM1.

NSX dFW after vMotion

NSX dFW after vMotion

Note: The NSX Manager is not involved in this vMotion since we don’t use the “Applied To” feature (Explained later).

NSX Firewall Applied To:

By default when we’re creating a firewall rule in NSX, the “Applied to” field is set to “Distributed Firewall”. The firewall rule will be stored in NSX manager’s database and will be applied to all VMs vNICs, regardless of the VMs location. It’s important to mention that even when dFW rule is applied to all VMs, we still need a match on source/destination to take action on that rules.

The Applied To field is determined by vSphere objects: Cluster, Datacenter, vDS Distributed PortGroup, Logical Switch, Edge, Host system, Security Group, VM, or even vNIC!

NSX Apply To option

NSX Apply To option

When we start using the “Applied To” field, NSX Manager will map the “Applied To object to the corresponding vSphere cluster. Only ESXi hosts in the cluster will receive this rule.

Each ESXi host that receives this rule will use vShiled-Statefull-Firewal demon to parse it and figure out which VMs need to apply it. When using the “Applied To” field, the perimeter scope limit is the vSphere Cluster.

The shows below “Rule ID” 1002 in which we’ve configured “Applied To” Distributed Firewall. (Default behavior)

NSX Apply To 3

When we will push this firewall rule, NSX manager will send this rule to all vSphere clusters.

As a result: all VMs will get rule id 1002 at their vNic level.

 NSX Apply To 1

Continue our example we add another rules ID 1005 in which we use the “Applied To” on web-sv-01a and web-sv-01b. “Rule ID” 1002 stay the same with “Applied To” Distributed Firewall.

NSX Apply To 2

Assuming we have the following machines: web-sv-01a, web-sv-02a, app-sv-01A and sec-mgr-01a. And we’ve configured the rules above.

If web-sv-01a and app-sv-01A is part of “Computer Cluster A”, web-sv-02a is part of “Computer Cluster B” and sec-mgr-01a run in “Management Edge Cluster”.

Now when we push this policy the NSX Manager need will figure rules boundaries for each cluster.

NSX Apply To 4

Base this rules calculation NSX manager will push the firewall update to only to “Compute Cluster A” and “Compute Cluster B” , “Management Edge Cluster” will not receive any update because is not any vSphere object part of the “Applied To” filed. When “Compute Cluster A” received this rule firewall update vSIP kernel module will need to pars which VM will need to apply rule 1005. only web-sv-01a will get update new rule id 1005 In addition to old rule id 1002. VM name app-sv-01a will not get any firewall rule update. When “Compute Cluster B” received the rule update all ESXi host will get the firewall update inside the cluster, vSIP demon will parse it but only the ESXi host run VM name we-sv-01b will applied rule id 1005.


Applied To” benefits:

  • Reduce the amount of rules per VMware-sfw, this improves efficiency because the DFW will have less rules to evaluate for every new session.
  • In case of an overlap IP address within multi-tenancy environment we must use “Applied To” to distinguish between one tenant and others.



Cross cluster vMotion with “Apply To”:

When we do use the “Applied To” feature and the VM traffic perform a vMotion across clusters then the NSX Manger will be involved in the process to update destination VM cluster with the relevant firewall rules. The NSX manager must be up to complete this operation.

For example VM name web-sv-01a need to vMotion from Compute cluster A to Management Edge Cluster, vCenter will send vMotion notification to NSX Manager, as a results NSX Manager will trigger policy push to all ESXi host in Management Edge Cluster. web-sv-01a will get same rule before vMotion occur with just change in the domain object from “domain-c25” to “domain-c7”

NSX Apply To 5


If the NSX Manager is down, No update rule will be push! When VM land on destination cluster no VM specific rule apply for that VM. Its important to note that when the NSX manager is down all existing VMs forwarding plane with DFW rules continue to work, only “New” VMs cannot have firewall rules until NSX Manager come back.

The NSX DFW keeps the rule table as a “.dat” file at the ESXi host at the following path:

/etc/vmware/vShiled-Statefull-Firewal/vsipfw_ruleset.dat .

Created in the cloud with Saaspose.Words. http://saaspose.com

NSX L2 to L4 Firewall:

The VMware NSX DFW can enforce security policy from L2 (Data Link Layer) to L4 (Transport Layer).

With L2 we can create DFW rules base on the MAC address or L2 protocol like: ARP,RARP,LLDP.

L3/L4 security rules can be enforced with a source/destination IP address or TCP/UDP ports.

VMware have list of 3-Party vendor (constantly growing list)


Default Policy:

The DFW enforce L2 rules before L3.

L2 Default policy: Fresh DFW installations will have a default policy, Which is a L2 policy with Source: Any, Destination: Any, Action: Allow


L3 Default Policy:

We have a default L3 policy with Source: Any, Distention: Any, Action: Allow


DFW Exclusion functionality:

Working on daily tasks with firewalls can sometimes lead to a situation where you end up blocking your access to the firewall management.
Regardless of the vendor you are working with, this is very challenging situation.
The end result of this scenario is that you are unable to access the firewall management to remove the rules that are blocking you from reaching the firewall management!

Think of a situation where you deploy a distributed firewall into each of your ESX hosts in a cluster, including the management cluster where you have your vCenter server located.

And then you change the default rule from the default “Allow” value to “Block” (as shown below):


What you’ve done by implementing this rule, can be shown in the following figure:

cut tree you sit on

Like the poor guy above dropping himself from his tree, by implementing this rule, you have blocked yourself from managing your vCenter.



OR: How can we protect ourselves from this situation?

Put your vCenter (and other critical virtual machines) in an exclusion list.
Any VM on that list will not receive any distributed firewall rules.
Go to the Network & security tab Click on NSX Manager


Exclusion VM list 1


Double click on the IP address object. In my example it is

Exclusion VM list 2


Click on Manage:

Exclusion VM list 3

Go in the “Exclusion List” tab and click on the green plus button.


Choose your virtual machine.


That’s it!  Now your VC is excluded from any enforced firewall rules.


Exclusion VM list 6


Restoring default firewall rules set:

We can use the NSX Manager REST API to revert to the default firewall rules set to overcome a mistake when we do not yet have access to the VC.

Perform a configuration backup at this stage.
By default the NSX Manager is automatically excluded from DFW, so it is always possible to send API calls to it.
Using a REST Client or cURL:


Submit a DELETE request to:



After receiving the expected code status 204 we will revert to the default DFW policy with default rule set to allow.


Now we can access our VC! . As we can see, we reverted to the default policy, but don’t panic :-)  as we saved the policy.


Click on the “Load Saved Configuration” button.


Load Saved Configuration before the last Saved.

Note: Every time we push dFW policy NSX automaticly save the policy. We have limit of 50 versions. 

Exclusion VM list 11

Accept the warning by click Yes.

Exclusion VM list 12

Now we have our last policy before we blocked our VC, it’s loaded but not applied.


We will need to change the last Rule from Block to Allow to fix the problem.


And Click “Publish the Changes”.



  • It’s not possible to disable the DFW functionality per vNIC, Exclusion List only allows to disable DFW functionality per VM.
  • The following list is automatically excluded from DFW functions, by default: The NSX Manager, NSX Controllers, Edge Service Gateway and Service VM (PAN FW for instance).


NSX and Application Level Gateway(ALG):

Application Level Gateway (ALG) is the ability of a firewall or a NAT device that can either allow or block applications that uses dynamic ephemeral ports to communicate. In the absence of ALG, it could be a nightmare for security and network administrators with the options of trade off between communication and security. A network administrator can suggest opening a large number of ports which would pose security threat for the network or the given server while a security administrator can suggest blocking all other ports except the known ports which again breaks the communication.ALG reads the network address found inside the application payload and opening respective ports for preceding communication and also synchronizing data across multiple sessions across different ports. For example: FTP uses different ports for session initiation/control connection and actual data transfers. An ALG would manage any information passed on the control connection as well as data connection in the above case.NSX-v acts as ALG for few protocols such as FTP, CIFS, ORACLE TNS, MS-RPC, SUN-RPC.


NSX DFW logs:

In NSX we have three different log types: System Events, Rule Events and Audit Messages and host Flows.

NSX Manager System Events

NSX Manager System Events are related to NSX operation like: FW configuration applied, Fail to publish FW configuration, Filter created, Filter deleted, VM added to Security Group.

For each System event have severity level:



To view the NSX System Events Go to Network & Security -> NSX Managers Click on the NSX Manager IP address -> Monitor -> System Events

Here is example for Critical event polled by NSX manager.

This event indicate vShiled-Statefull-Firewal demon went down on ESXi host id “host-38”.

We can view system event from the ESXi host itself. Here is example for FW configuration events can be view vShiled-Statefull-Firewal.log. this event cuase by  policy push from the NSX manager to ESXi host. The file location is: var/log/vShiled-Statefull-Firewal.log

Example for output:

2015-03-10T02:43:12Z vShiled-Statefull-Firewal: [INFO] Received vsa message of RuleSet, length 67

2015-03-10T02:43:12Z vShiled-Statefull-Firewal: [INFO] Processed vsa message RuleSet: 67

2015-03-10T02:43:12Z vShiled-Statefull-Firewal: [INFO] L2 rule optimization is enabled

2015-03-10T02:43:12Z vShiled-Statefull-Firewal: [INFO] applying firewall config to vnic list on host host-10

2015-03-10T02:43:12Z vShiled-Statefull-Firewal: [INFO] Enabling TCP strict policy for default drop rule.

2015-03-10T02:43:12Z vShiled-Statefull-Firewal: [INFO] sending event: applied vmware-sfw ruleset 1425955389291 for vnic 500e519a-87fd-4acd-cee2-c97c2c6291ad.000

2015-03-10T02:43:12Z vShiled-Statefull-Firewal: [INFO] successfully saved config to file /etc/vmware/vShiled-Statefull-Firewal/vsipfw_ruleset.dat

2015-03-10T02:43:12Z vShiled-Statefull-Firewal: [INFO] Sending vsa reply of domain-c7 host host-10: 0


NSX Manager Audit Events:

This log contains all the events related to: Admin login, FW configuration changes (pre and post change of the DFW rule).

To view the Audit Events Go to Network & Security -> NSX Managers Click on the NSX Manager IP address -> Monitor -> Audit Logs.

Here is Example for User bob login to system:


ESXi DFW host Rules Messages:

This log contains all the events related to: The DFW has dedicated log file (introduced in version 6.1) to view start/termination session and drop/pass packets. This logs contains the rule id associated vCenter objects.

File name is: dfwpktlogs.log

File location on the ESXi host:  /var/log/dfwpktlogs.log 

A log example: more /var/log/dfwpktlogs.log 

2015-03-10T03:22:22.671Z INET match DROP domain-c7/1002 IN 242 UDP>


1002 is the DFW rule-id

domain-c7 is cluster ID in the vCenter MOB. is the source IP destination IP


To view the Log filled we need to enable the “Log” option field.

By default when we create DFW rule there is no logging enabled. Logging occurs only after we enable the Log field on the firewall rules table

In order to see “Allow” or “Block” packet in the DFW logs files we need to change the “Log” field from “Do not log”  to “Log”.

In the following example we’re changing the last rule id 1002 from “Do no log” to “Log”:

In the next example for DFW log event we will see the results of a ping from my Control VM Management IP to

~ # tail -f /var/log/dfwpktlogs.log | grep

2015-03-10T03:20:31.274Z INET match DROP domain-c27/1002 IN 60 PROTO 1>

2015-03-10T03:20:35.794Z INET match DROP domain-c27/1002 IN 60 PROTO 1>


Live Flows:

With DFW we have ability to view live flows. These flows are pulled by the vShiled-Statefull-Firewal from the vSIP kernel module and aggregated appropriately. The NSX Manager pulls normal flows from vShiled-Statefull-Firewal every 5 minutes and realtime flows every 5 secs.

Enable the Flow Monitoring by clicking on “Flow Monitoring” -> Configuration and click on the Enable. Global Flow Collection should change to green, “Enabled” status

To View the vNIC flow go to “Live Flow” tab and browse for a specific VM and vNIC.

Click the start button

Live flow will show up in the screen. The refresh Rate is 5 second.

From ESXi host the /var/log/vsfwd.log file we can see the related events:

2015-03-18T03:20:01Z vShiled-Statefull-Firewal: [INFO] Received vsa message of FlowConfiguration, length 120

2015-03-18T03:20:01Z vShiled-Statefull-Firewal: [INFO] Processed vsa message FlowConfiguration: 120

2015-03-18T03:20:01Z vShiled-Statefull-Firewal: [INFO] Loaded flow config: [120]

2015-03-18T03:21:29Z vShiled-Statefull-Firewal: [INFO] Received message in request queue of topic FlowRequest

2015-03-18T03:21:29Z vShiled-Statefull-Firewal: [INFO] Received vsa message of FlowRequest, length 52

2015-03-18T03:21:29Z vShiled-Statefull-Firewal: [INFO] Processed vsa message FlowRequest: 52

2015-03-18T03:21:29Z vShiled-Statefull-Firewal: [INFO] rmqRealTimeFlowDataRetrieve started

2015-03-18T03:21:29Z vShiled-Statefull-Firewal: [INFO] Done with configuring start of real time flows

2015-03-18T03:21:29Z vShiled-Statefull-Firewal: [INFO] rmqRealTimeFlowDataPush started


Service Composer:

Service Composer helps you to provision and assign network and security services to applications in a virtual infrastructure.

You map these services to a security group, and the services are applied to the virtual machines in the security group

Security group

With NSX DFW we have the ability to group vCenter elements such as VMs to container called security groups. Base of this security groups we can built DFW rules. The of what vSphere object can be part of the security group can be dynamic or static.

Security group can be consume directly in to firewall tab without use the service composer.


Security Group = (Dynamic Inclusion + Static Inclusion) – Static Exclusion

Creating Security groups base of VM name example:

Go to Network & Security -> Service Composer -> Security Groups



Dynamic inclusion:

A list of dynamic options for inclusion.

In the example below we chose “VM name” for any VM contains the word “web”:


Static Inclusion:

We can select the object type that we want to (permanently) include as part of this security group.

With static inclusion we can create nested security groups.

  • Nested groups are group inside groups.

In the following example we will not exclude any object:

 Static exclusion:

We can select what is the object type we want to permanently exclude as part of this security group.



Summary of Security Group:


We can view the security group object members from the “Security Groups tab.

In our example, the “Web Servers” security has two VMs: web-sv-01 and web-sv-02a and this group membership is handled dynamically because the criteria is that they have “web” as part of their VM name.

If a new VM, called web-sv-03a” is being created in this vCenter it will automatically be part of this security group.


Security policy using security groups:

We can create a firewall rule that leverage this new security group:

Source can be any and destination will be the “Web Servers” security group.

The service can be one L4 service or group of services, here we chose HTTPS. 


We can apply this policy to any cluster running NSX “Distributed Firewall”.

We can apply this policy on security groups, which will result in the rule (policy) applied only to VMs that are part of this security groups.

The security rule:

vSphere environments are dynamic by nature. When new VMs join (or leave) a security group (ex. “Web Servers”) the vCenter will update his database and as a result an update notification will be sent to the NSX manager. This notification will trigger a list of updates to the VMs that are part of this security group due to being part of the “Applied To”.  Security administrator do not need to constantly update the policy rules for every time new VMs join or leave the network. NSX firewall policy can automatically reflect these changes and this is the reason using vCenter objects is so powerful



Security tag:

To keep the virtualization flexibility, without compromise security, VMware invented security tag.

By adding new tag attribute to VMs we can apply security policy.  Adding or removing tag to VM can be done dynamically by automation, 3-Party or even manual.

We can use the example we used above in which we created a security group called Web Servers”, but rather than use a VM name containing “web” as the criteria for this VM group membership, we can attach a security tag to this VM.

Create Manual Security tag:


Create the security tag name:

We have a user defined security tag with 0 VM count:


Manual apply Security Tag:

Select the “web servers” security tag name and right click.


Filter “web” from the list and choose web-sv-01a and web-sv-02a from list:

Now we can modify the “Web servers” security policy to use a dynamic including criteria:


After this changed we have two VM count with security tag “web servers”.


The security groups “Web serverscontains the VM names: web-sv-01a and web-sv-02a.



In the VMs summary page we can see the security tags that are applied to this VM and to which security group this VM belongs. From the “web-sv-01a” example:

Security Policy:

Using security policy we can create templates containing DFW policy approved security admin this is “how you want to protect” your environment, then apply this on security groups “WHAT you want to protect”. Security policy may contain traffic redirection rules to 3rd-party vendors for service chaining.

Security policy is part of the service composer building blocks.

We can apply a security policy to more than one security group.

In the example below we apply “Web Security Policy” to both “Security Group 1” and Security Group 2”.




A different option is to apply two different security policies to same security groups.

This can result in a contradiction between the policies.

For example we apply “Security Policy 1 and Security Policy 2 to “WEB Security Groups”:

The security policy precedency will be with a “Weight” value, configured by the security admin

In the following example we demonstrate this when we create two different security policies: “Allow ICMP SP” and “Allow HTTP SP” and apply both to the previously created security group “Web Servers.

Create “Allow ICMP SP:


In create “Firewall Rules”: The “Weight is 4300

  • The related action is Allow
  • The source filled is: any
  • Destination is: “Policy Security Groups”.

The following is the interesting part: Due to the fact that this security policy works as a template we may reuse it for different security groups and our goal is to avoid tying this template to a specific security group.

Service: ICMP ECHO Request, ICMP ECHO Replay.


Ready to compute and click Finish:


At the firewall tab we can note that at this stage:

  • We have not applied this security policy to any security groups and so this policy has not been activated yet. We can see it as the gray policy in the firewall tab.
  • There is no security group in the designation:


Create Allow WEB SP” is the same way:

Notice that the “Weight field is 1300, which is lower than the previous “Allow ICMP SP” 4300

Cerate the WEB rule (same flow as above):


The firewall policy order shows “Allow ICMP” before “Allow WEB”

Now we apply both security policies on the same security group, using “Apply Policy”:

Choose “Allow ICMP Security Policy”:

And do the same for the second security policy called “Allow WEB SP”.

In the “Security Policy tab view we can see the results of this action:

From the “Firewall tab we can see that now we have two activated service composer security rules.

In the service composer canvas view we have an excellent summery of the security services which were applied to the security group:


3rd party vendor service integration

The NSX DFW can integrate with 3rd party vendors to achieve a higher level of application security level with different services. The partner needs to register their service on NSX manager.

We define the traffic redirection policy in service composer.

For example, we can redirect the traffic that leaves/enters the VMs to a third party partner product device for inspection.

We can define traffic redirection in two different places.

Using “Partner Security Service”:

In this example with a Palo Alto firewall we define the “any” source traffic , designated to PAN-SG-WEB security group, will be redirected to the PAN firewall:


Using security policy:


We follow the same policy definition construct as DFW (i.e. same options for source field, destination field and services field) and the only difference is in the action field: instead of Block/Allow/Reject, a user can select between redirect/no redirect followed by a partner list (any partner that has been registered with NSX and that has been successfully deployed on the platform).Finally: Log options can be enabled for this traffic redirection rule.

Install NSX DFW:

NSX DFW Pre-requirements:

Table 1 list vSphere pre-requirements for NSX DFW

vCenter ESXi host NSX Manager VMtools vSphere Switch
5.5 or later 5.1,5.5 6.0 or later VMtoool must install and run on VM guest OS if DFW policy base on vCenter objects.
VMtools can be Any version
vMware Distributed switch (vDS)
version 5.1 or later.
VSS is not supported


It’s imported to mention that NSX DFW can work on VXLAN port-group or VLAN port-group.  Enable dFW on vSS is not tested by VMware and No supported mean if you enable it, it may work.

NSX Controller is not required with DFW. NSX Controller is only required for VXLAN and Logical Distributed Router.

The NSX DFW installation is done through the Host preparation process.

The NSX Manager triggers the NSX kernel modules installation inside a vSphere cluster and builds the NSX Control plan fabric.

Note: Before the host preparation process we need to complete the following:

  • Registering the NSX Manager with vCenter.
  • Deploying the NSX Controllers.

Three components are involved during the NSX host preparation: vCenter, NSX Manager, EAM (ESX Agent Manager).

Host Preperation1

vCenter Server:
Management of vSphere compute infrastructure.

NSX Manager:
Provides the single point of configuration and REST API entry-points in a vSphere environment for NSX.

EAM (ESX Agent Management):
The middleware component between the NSX Manager and the vCenter. The EAM is part of the vCenter and is responsible to install the VIBs (vSphere Installation Bundles), which are software packages prepared to be installed inside an ESXi host.


The host preparation begins when we click the “Install” button in the vCenter GUI.

  • This process is done at the vSphere Cluster level and not per ESXi host.
  • The EAM will create an agent to track the VIB’s installation process for each host. The VIB’s are being copied from the NSX Manager and cached in EAM. If the VIBs are not present in the ESXi host, the EAM will install the VIBs (ESXi host reboot is not needed at the end of this process).
  • During an NSX software upgrade, the EAM also takes care of removing the installed old version of the VIBs but an ESXi host reboot is then needed.

VIBs installed during host preparation:

  • esxdvfilter-switch-security
  • esx-vsip
  • esx-vxlan

Once the host preparation was successfully completed the ESXi host has a fully working Control Plane.

 Two control plan channels will be created:

  • RabbitMQ (RMQ) Message bus: Provides communication between the vShiled-Statefull-Firewal process on the ESXi hypervisor and the NSX Manager over TCP/5671.
  • User World Agent (UWA) process (netcpa on the ESXi hypervisor): Establishes TCP/1234 connection over SSL communication channels to the Controller Cluster nodes.

Troubleshooing DFW installation:

The NSX DFW installation is actually the host preparation process.

We have few examples for host preparation issues.

DNS Issues:

EAM fails to deploy VIBs due to misconfigured DNS or no DNS configuration on host.
We can verify if those DFW VIBs have been successfully installed by connecting to each ESXi host in the cluster and issuing the command “esxcli software vib list”.

~# esxcli software vib list | grep esx-vsip

esx-vsip                       5.5.0-0.0.2318233                     VMware  VMwareCertified   2015-01-24

~ # esxcli software vib list | grep dvfilter

esxdvfilter-switch-security   5.5.0-0.0.2318233                     VMware  VMwareCertified   2015-01-24


In this case, we may get a status of “Not Ready”:

Not Ready

The message clearly indicates “Agent VIB module not installed” on one or more hosts.

We can check the vSphere ESX Agent Manager for errors:

vCenter home > vCenter Solutions Manager > vSphere ESX Agent Manager”

On “vSphere ESX Agent Manager”, check the status of “Agencies” prefixed with “_VCNS_153”. If any of the agencies has a bad status, select the agency and view its issues:


We need to check the associated log  /var/log/esxupdate.log (on the ESXi host) for more details on host preparation issues.
Log into the ESXi host in which you have the issue, run “tail /var/log/esxupdate.log” to view the log

esxupdate error1

From the log it appears suddenly clear that the issues may be related to DNS name resolution.

Configure the DNS settings in the ESXi host for the NSX host preparation to succeed.


TCP/80 from ESXi to vCenter is blocked:

The ESXi host is unable to connect to vCenter EAM on TCP/80:

Could be caused by a firewall blocking communication on this port. From the ESXi host /var/log/esxupdate.log file:

esxupdate: esxupdate: ERROR: MetadataDownloadError: (‘http://VC_IP_Address:80/eam/vib?id=xxx-xxx-xxx-xxx), None, “( http://VC_IP_Address:80/eam/vib?id=xxx-xxx-xxx-xxx), ‘/tmp/tmp_TKl58’, ‘[Errno 4] IOError: <urlopen error [Errno 111] Connection refused>’)”)

The NSX-v has a list of ports that need to be open in order for the host preparation to succeed.
The complete list can be found in:

Existing VIB’s Version

If an old VIBs version exists on the ESXi host, EAM will remove the old VIB’s
But the host preparation will not automatically continue.

We will need to reboot the ESXi host to complete the process (this condition will be clearly indicated next to the host name on vCenter).


ESXi bootbank space issue:

If you try Upgrade ESXi 5.1u1 to ESXi 5.5 and then start NSX host preparation you may face issue and from /var/log/esxupdate log file you will see message like:
Installationerror: the pending transaction required 240MB free space, however the maximum size is 239 MB”
I faced this issue in a customer ISO of IBM blade but may appear in other vendors.

Install fresh ESXi 5.5 Custom ISO. (This is the version I upgraded too)



If the vCenter runs on a Windows machine, other applications can be installed and already using port 80, causing a conflict with EAM port tcp/80.

For example: By default IIS server use TCP/80

Use a different port for EAM:

Changed the port to 80 in eam.properties in \ProgramFiles\VMware\Infrastructure\tomcat\webapps\eam\WEB-INF\


Download VIBs link:

The NSX manager has a direct link to download the VIB’s as zip file:



Reverting installation:

Reverting a NSX Prepared ESXi Host requires the following steps:

  • Remove the host from the vSphere cluster.
  • Put ESXi host in maintenance mode and remove the ESXi host from the cluster. This will automatically uninstall NSX VIBs.

Note: ESXi host must be rebooted to complete the operation.

Manually Uninstall VIBs:

The following commands can be entered directly on the ESXi host to remove the installed NSX VIBs:

esxcli software vib remove -n esx-vxlan

esxcli software vib remove -n esx-vsip

esxcli software vib remove -n dvfilter-switch-security

Note: The ESXi host must be rebooted to complete the operation

DFW (UWA) agent issues:

The VIBs installation completes successful but on rare occasions one or both user world agents is not functioning correctly. This could manifest itself as either:

  • The firewall showing a bad status Error for example.
  • The control plane between the hypervisor(s) and the controllers is being down

UWA error

Validate Message bus service is active on NSX Manager:

Check the messaging bus userworld agent status by running the command/etc/init.d/vShieldStateful-Firewall status on the ESXi hosts



vShiled-Statefull-Firewal is the service daemon part of UWA (User Web Agent) running on ESXi host.

To check if vShiled-Statefull-Firewal daemon is working properly, issue the following CLI

~ # ps | grep vShiled-Statefull-Firewal

36169 36169 vShiled-Statefull-Firewal                /usr/lib/vmware/vsfw/vShiled-Statefull-Firewal

36170 36169 vShiled-Statefull-Firewal                /usr/lib/vmware/vsfw/vShiled-Statefull-Firewal

36171 36169 vShiled-Statefull-Firewal                /usr/lib/vmware/vsfw/vShiled-Statefull-Firewal

36172 36169 vShiled-Statefull-Firewal                /usr/lib/vmware/vsfw/vShiled-Statefull-Firewal

36173 36169 vShiled-Statefull-Firewal                /usr/lib/vmware/vsfw/vShiled-Statefull-Firewal

36174 36169 vShiled-Statefull-Firewal                /usr/lib/vmware/vsfw/vShiled-Statefull-Firewal

36175 36169 vShiled-Statefull-Firewal                /usr/lib/vmware/vsfw/vShiled-Statefull-Firewal

36176 36169 vShiled-Statefull-Firewal                /usr/lib/vmware/vsfw/vShiled-Statefull-Firewal

36178 36169 vShiled-Statefull-Firewal                /usr/lib/vmware/vsfw/vShiled-Statefull-Firewal

36179 36169 vShiled-Statefull-Firewal                /usr/lib/vmware/vsfw/vShiled-Statefull-Firewal

36909 36169 vShiled-Statefull-Firewal                /usr/lib/vmware/vsfw/vShiled-Statefull-Firewal


The ESX shows the threads this way, these are not processes but are threads.

The vShiled-Statefull-Firewal provided activates are performed by several threads:


  • Firewall Rule publishing, Flow monitoring, NetX config thread, heart beat, threshold monitoring, ipfix, netcpa proxy etc… Are all supported vShiled-Statefull-Firewal activities that are run by these threads.

Run the below command on the ESXi hosts to check for active messaging bus connection:

esxcli network ip connection list | grep 5671 (Message bus TCP connection)

network connection

Please ensure that port 5671 is opened for communication in the any external network firewall.

Logs are recorded under /var/log/vswfd.log. If the Message Bus is communicating properly with the VSM, you should see logs as follows (Heartbeats):

2015-03-10T14:10:34Z vShiled-Statefull-Firewal: [INFO] Received HeartBeart Seq 2545 , Sending response

2015-03-10T15:22:34Z vShiled-Statefull-Firewal: [INFO] Received HeartBeart Seq 2569 , Sending response

2015-03-10T16:34:34Z vShiled-Statefull-Firewal: [INFO] Received HeartBeart Seq 2593 , Sending response

2015-03-10T17:46:34Z vShiled-Statefull-Firewal: [INFO] Received HeartBeart Seq 2617 , Sending response



Since this is a module which operates at the kernel level, it is highly unlikely that the module would fail as it gets loaded as a part of the boot image. However, in case of any failures of the distributed firewall functionality; for an instance an ESXi host maxed out on the CPU, the traffic would be blocked by default and packets would start dropping for the VMs which are protected.

In event when vShiled-Statefull-Firewal is down:

          You would see “messaging infrastructure down on host” in System Events (with host name)

          New rules will not get pushed to the host. DFW UI would indicate last publish operation is pending (as opposed to succeeded …true even if its one out of 100 host that push failed).

          In all cases, Enforcement of all/any of already programmed rules will Never stop.

          If the vShiled-Statefull-Firewal crashes on the host,

          A watchdog process will restart it automatically.

          The downtime involved will be not observable as the restart is pretty quick.

          Every time a vShiled-Statefull-Firewal restart occurs, the NSX manager is contacted to sync all the rules info to make sure the state is in sync between the NSX manager and the host.

         If the vShiled-Statefull-Firewal is stopped manually on the host (i.e “/etc/init.d/vShieldStateful-Firewall stop”). Then there is no attempt to restart the process.


esxcfg-advcfg -l | grep Rmq

Run this command on the ESXi hosts to show all Rmq variables –there should be 16 variable in total

esxcfg-advcfg -g /UserVars/RmqIpAddress

Run this command on the ESXi hosts, it should display the NSX Manager IP address



DFW Kernel Space:

Verify that the Kernel Module was loaded to memory:

VSIP (VMware Internetworking Service Insertion Platform) is the distributed firewall kernel module component

Command to check if distributed firewall kernel module is successfully installed on the host:


~ # vmkload_mod -l | grep vsip

vsip                     13   452


This command display all IOChains and firewall filter on ESXi host.


Fast Path = traffic filter in the Kernel module

Slow Path = Traffic redirected to 3-Party vendor like PaloAlto . In this screenshot we can see there is no Slow Path.

Filters: tied display for etch vNIC in this esxi host what Slot he belong to.


In Fastpath we can see the filter orders start from SLOT 0 dvfilter-faulter.


~ # summarize-dvfilter


agent: dvfilter-faulter, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter

agent: ESXi-Firewall, refCount: 5, rev: 0x1010000, apiRev: 0x1010000, module: esxfw

agent: vmware-sfw, refCount: 2, rev: 0x1010000, apiRev: 0x1010000, module: vsip

agent: dvfilter-generic-vmwareswsec, refCount: 2, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter-switch-security

agent: bridgelearningfilter, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: vdrb

agent: dvfilter-generic-vmware, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter-generic-fastpath

agent: dvfg-igmp, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfg-igmp




port 50331654 vmk2

  vNic slot 0

   name: nic-0-eth4294967295-ESXi-Firewall.0

   agentName: ESXi-Firewall

   state: IOChain Attached

   vmState: Detached

   failurePolicy: failOpen

   slowPathID: none

   filter source: Invalid


port 50331655 vmk3

  vNic slot 0

   name: nic-0-eth4294967295-ESXi-Firewall.0

   agentName: ESXi-Firewall

   state: IOChain Attached

   vmState: Detached

   failurePolicy: failOpen

   slowPathID: none

   filter source: Invalid


world 35677 vmm0:web-sv-02a vcUuid:’50 26 b7 4d c5 6c 1e d9-47 c0 09 25 95 80 2f ad’

 port 50331656 web-sv-02a.eth0


vNic slot 2

   name: nic-35677-eth0-vmware-sfw.2

   agentName: vmware-sfw

   state: IOChain Attached

   vmState: Detached

   failurePolicy: failClosed

   slowPathID: none

   filter source: Dynamic Filter Creation


vNic slot 1

   name: nic-35677-eth0-dvfilter-generic-vmware-swsec.1

   agentName: dvfilter-generic-vmwareswsec

   state: IOChain Attached

   vmState: Detached

   failurePolicy: failClosed

   slowPathID: none

   filter source: Alternate Opaque Channel


Packet capture command:


When VM connect to Logical switch NSX will implement different IOChains security services in the VM packet flow. Each service represents with unique slot id.

IN the figure shows below we have VM name Web-sv-01a part of ESXi host name esxcomp-01a. web-sv-01a have tree different IOChains before the VM packet get to vDS port-group. This IOChains handle VM packet process at the Kernel level.


Slot 0: DVFilter (Distributed Virtual Filter):

Distributed Virtual Filter DVFilteris is the VMkernel between the protected vNIC at SLOT 0 associated Distributed Virtual Switch (DVS) port, and is instantiated when a virtual machine with a protected virtual NIC gets created. It monitors the incoming and outgoing traffic on the protected virtual NIC and performs stateless filtering.

Slot 1: sw-sec (Switch Security): sw-sec module learns VMs IP and MAC address. sw-sec is critical component capture DHCP Ack and ARP broadcast message and forward this info as unicast to NSX Controller to perform the ARP suppression feature. sw-sec is the layer where NSX IP spoofgurd is implemented,



Slot-2: VMware-sfw: This is the place where DFW firewall rules are stored and enforced, VMware-sfw contains rules table and connections table.

With vSphere we can capture VMs traffic with command pktcap-uw, for this example we send continuous ping (ICMP echo request) packet from web-sv-01a. The capture command will need to be place on IOChain SLOT 2 with appropriate filter name for web-sv-01a.

To find the exact filter name we need to use the command summarize-dvfilter.

We can grep the exact name with the –A 3 switch mean show 3 line more after the grep term found.

From ESXi host name esxcomp-01a:

~ # summarize-dvfilter | grep web-sv-01a  –A 3

world 35682 vmm0:web-sv-01a vcUuid:’50 26 c7 cd b6 f3 f4 bc-e5 33 3d 4b 25 5c 62 77′

 port 50331656 web-sv-01a.eth0

  vNic slot 2

   name: nic-35682-eth0-vmware-sfw.2

   agentName: vmware-sfw


From this output we can see that the filter name is nic-35682-eth0-vmware-sfw.2 for SLOT 2

pktcap-uw command help with -A output:

esxcomp-01a # pktcap-uw -A

Supported capture points:

        1: Dynamic — The dynamic inserted runtime capture point.

        2: UplinkRcv — The function that receives packets from uplink dev

        3: UplinkSnd — Function to Tx packets on uplink

        4: Vmxnet3Tx — Function in vnic backend to Tx packets from guest

        5: Vmxnet3Rx — Function in vnic backend to Rx packets to guest

        6: PortInputPort_Input function of any given port

        7: IOChain — The virtual switch port iochain capture point.

        8: EtherswitchDispath — Function that receives packets for switch

        9: EtherswitchOutput — Function that sends out packets, from switch

        10: PortOutput — <

Related Blog post:

An introduction to Zero Trust virtualization-centric security

What is a Distributed Firewall?

Deep Dive: How does NSX Distributed Firewall work

Distributed Firewall (DFW) in NSX for vSphere, and “Applied To:”

Security-as-a-Service with NSX Service Composer

Configure and Administer Firewall Services

Service Composer – Resultant Set of Policy

Validating Distributed Firewall rulesets in NSX

Stateful Firewall and NSX


Thanks to Tiran Efrat and Francis Guillier for reviewing this document and answering some of the questions during creating this document.

Asymmetric routing with ECMP and Edge Firewall Enabled

What is Asymmetric Routing?

In Asymmetric routing, a packet traverses from a source to a destination in one path and takes a different path when it returns to the source.

Start from version 6.1 NSX Edge can work with ECMP – Equal Cost Multipath, ECMP traffic involved Asymmetric routing between Edges and DLR or between Edge and physical routers.

ECMP Consideration with Asymmetric Routing

ECMP with  Asymmetric routing is not a problem by itself, but will cause problems when more than one NSX Edge in place  and stateful services inserted in the path of the traffic.

Stateful services like firewall, Load Balanced  Network Address Translation (NAT) can’t work with asymmetric routing.

Explain the problem:

User from outside try to access Web VM inside the Data Center. the traffic will pass through E1 Edge.

From E1 the traffic will go to DLR transverse NSX distributed firewall and get to Web VM.

When Web VM respond back the traffic will hit the DLR default gateway. DLR have two option to route the traffic E1 or E2.

If DLR choose E2 the traffic will get the E2 and will Dropped !!!

The reason for this is E2 does not aware the state of session started at E1, replay packet from Red VM arrived to E2 are not match any existing session at E2.
From E2 perspective this is new session need to validate, any new TCP session should start with SYN, since this is not the begin of the session E2 will drop it!!!

Asymmetric Routing with Edge Firewall Enabled

Asymmetric Routing with Edge Firewall Enabled

Note: NSX Distributed firewall is not part of this problem, NSX Distributed firewall implement at the vNic level, all traffic get in/out same vNic.

there is no Asymmetric route in the vNic level, btw this is the reason when we vMotion VM, the Firewall Rule, Connection state is move with the VM itself.

ECMP and Edge Firewall NSX

Starting from version 6.1 when we enable ECMP  on NSX Edge get message:

Enable ECMP in 6.1 version

The firewall service disabled by default:

Enable ECMP in 6.1 version Firewall turnoff

Even if you try to enable it you will get warning message:

Firewall Service in 6.1 with ECMP

In version 6.1.2 when we enable ECMP we get same message:

Enable ECMP in 6.1 version

But the BIG difference is Firewall Service  is Not disable by default. (you need to turn it off)

Even if you have “Any, Any” rule with “Accept” action we still be subject for DROP packet subject of the Asymmetric routing problem!!!

Firewall Service Enable in 6.1.2

Even in Syslog or LogInSight you will not see this DROP packet !!!

The end users expirese for will be some of the session’s are working just fine (this sessions are not asymmetric) other session will drop (asymmetric sessions)

The place i found we can learn packet are drops because state of the session is with the command: show tech-support:

show tech-support
vShield Edge Firewall Packet Counters:
~~~~~~~~~~~~~~~ snip ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
rid    pkts bytes target     prot opt in     out     source               destination         
0        20  2388 ACCEPT     all  --  *      lo             
0        12   720 DROP       all  --  *      *              state INVALID
0        51  7108 block_out  all  --  *      *             
0         0     0 ACCEPT     all  --  *      *              PHYSDEV match --physdev-in tap0 --physdev-out vNic_+
0         0     0 ACCEPT     all  --  *      *              PHYSDEV match --physdev-in vNic_+ --physdev-out tap0
0         0     0 ACCEPT     all  --  *      *              PHYSDEV match --physdev-in na+ --physdev-out vNic_+
0         0     0 ACCEPT     all  --  *      *              PHYSDEV match --physdev-in vNic_+ --physdev-out na+
0         0     0 ACCEPT     all  --  *      *              state RELATED,ESTABLISHED
0        51  7108 usr_rules  all  --  *      *             
0         0     0 DROP       all  --  *      *  

From line 7 we can see DROP packet because of INVALID state.


When you enable ECMP and you have more then one NSX Edge in you topology, go to Firewall service and disable it by yourself otherwise you will spend lots of troubleshooting hours 🙁


Thanks to Francis Guillier Max Ardica and  Tiran Efrat of the overview and feedback.

One of the most important NSX Edge features is NAT.
With NAT (Network Address Translation) we can change the Source or Destination IP addresses and TCP/UDP port. Combined NAT and Firewall rules can lead to confusion when we try to determine the correct IP address to which apply the firewall rule.
To create the correct rule we need to understand the packet flow inside the NSX Edge in details. In NSX Edge we have two different type of NAT: Source Nat (SNAT) and Destination NAT (DNAT).



Allows translating an internal IP address (for example private IP described in RFC 1918) to a public External IP address.
In figure below, the IP address for any VM in VXLAN 5001 that needs outside connectivity to the WAN can be translated to an external IP address (this mapping is configured on the Edge). For example, VM1 with IP address needs to communicate with WAN Internet, so the NSX Edge can translate it to a IP address configured on the Edge external interface.
Users in the external network are not aware of the internal Private IP address.




Allow to access internal private IP addresses from the outside world.
In the example in figure below, users from the WAN need to communicate with the Server
NSX Edge DNAT mapping configuration is created so that the users from outside connect to and NSX Edge translates this IP address to


Below is the outline of the Packet flow process inside the Edge. The important parts are where the SNAT/DNAT Action and firewall decision action are being taken.

packet flow

We can see from this process that the ingress packet will evaluate against FW rules before SNAT/DNAT translation.

Note: the actual packet flow details are more complicated with more action/decisions in Edge flow, but the emphasis here is on the NAT and FW functionalities only.

Note:  NAT function will work only if firewall service is enabled.

Enable Firewall Service



Firewall rules and SNAT

Because of this packet flow the firewall rule for SNAT need to be applied on the internal IP address object and not on the IP address translated by the SNAT function. For example, when a VM1 needs to communicate with the WAN, the firewall rule needs to be:

fw and SNAT

 Firewall rules and DNAT

Because of this packet flow the firewall rules for DNAT need to be applied on the public IP address object and not on the Private IP address after the DNAT translation. When a user from the WAN sends traffic to, this packet will be checked against this FW rule and then the NAT will change the destination IP address to

fw and DNAT

DNAT Configuration

Users from outside need to access an internal web server connecting to its public IP address.
The server internal IP address is, the NAT IP address is



The first step is creating the External IP on the Edge, this IP is secondary because this edge already has a main IP address configured in the IP subnet.

Note: the main IP address is marked with a black Ddot (

For this example the DNAT IP address is


Create a DNAT Rule in the Edge:


Now pay attention to the firewall rules one the Edge: a user coming from the outside will try to access the internal server by connecting to the public IP address This implies that the fw rule needs to allow this access.



DNAT Verification:

There are several ways to verify NAT is functioning as originally planned. In our example, users from any source address access the public IP address, and after the NAT translation the packet destination IP address is changed to

The output of the command:

show nat

show nat

The output of the command:

show firewall flow

We can see that packet is received by the Edge and destined to the address, the return traffic is instead originated from the different IP address (the private IP address).
That means DNAT translation is happening here.

show flow

We can capture the traffic and see the actual packet:
Capture Edge traffic on its outside interface vNic_0, in this example user source IP address is and destination is

The command for capture is:
debug packet display interface vNic_0 port_80_and_src_192.168.110.10

Debug packet display interface vNic_0 port_80_and_src_192.168.110.10

debug packet 1

Capture edge on internal interface vNic_1 we can see destination IP address has changed to because of DNAT translation:

debug packet 2

SNAT configuration

All the servers part of VXLAN segment 5001 (associated to the IP subnet need to leverage SNAT translation (in this example to IP address on the outside interface of the Edge to be able to communicate with the external network.


SNAT config

SNAT Configuration:

snat config 2

Edge Firewall Rules:

Allow to to go out

SNAT config fw rule



The output of the command

Show nat

show nat verfication

DNAT with L4 Address Translation (PAT)

DNAT with L4 Address Translation allows changing Layer4 TCP/UDP port.
For example we would like to mask our internal SSH server port for all users from outside.
The new port will be TCP/222 instead of regular SSH TCP/22 port.

The user originates a connection to the Web Server on destination port TCP/222 but the NSX Edge will change it to TCP/22.


From the command line the show nat command:

PAT show nat

NAT Order

In this specific scenario, we want to create the two following SNAT rules.

  • SNAT Rule 1:
    The IP addresses for the devices part of VXLAN 5001 (associated to the IP subnet need to be translated to the Edge outside interface address
  • SNAT Rule 2:
    Web-SRV-01a on VXLAN 5001 needs its IP address to be translated to the Edge outside address

nat order

In the configuration example above, traffic will never hit rule number 4 because is part of subnet, so its IP address will be translated to (and not the desired

Order for SNAT rules is important!
We need to re-order the SNAT rules and put the more specific one on top, so that rule 3 will be hit for traffic originated from the IP address, whereas rule 4 will apply to all the other devices part of IP subnet

nat reorder

After re-order:

nat after reorer


another useful command

show configuration nat


NSX Role Based Access Control

One of the most challenging problems in managing large networks is the complexity of security administration.

“Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of an individual user to perform a specific task, such as view, create, or modify a file. Roles are defined according to job competency, authority, and responsibility within the enterprise”

Within NSX we have four built in roles, We can map User or Group to one of the NSX Role. but i think Instead of assigning roles to individual users the preferred way is to assigning role to group.

Organizations create user groups for proper user management. After integration with SSO, NSX Manager can get the details of groups to which a user belongs to.

NSX Roles

Within NSX Manager we have four pre built RBAC roles cover different nsx permission and area in NSX environment.

The four NSX built in roles are: Auditor, Security Administrator, NSX administrator and Enterprise Administrator:

NSX RBAC Diagram

NSX RBAC Diagram

Configure the Lookup Service in NSX Manager

Whenever we want to assign role on NSX, we can assign role to SSO User or Group. When Lookup service is not configured then the group based role assignment would not work i.e the user from that group would not be able to login to NSX.

The reason is we cannot fetch any group information from the SSO server. The group based authentication provider is only available when Lookup service is configured. User login where the user is explicitly assigned role on NSX will not be affected. This means that the customer has to individually assign roles to the users and would not be able to take advantage of SSO groups.

For NSX, vCenter SSO server is one of the identity provider for authentication. For authentication on NSX, prerequisite is that the user / group has to be assigned role on NSX.

NSX Manager Lookup Service

NSX Manager Lookup Service

Note: NTP/DNS must configure on the NSX Manager for lookup service to work.

Note: The domain account must have AD read permission for all objects in the domain tree. 

Configure Active Directory Groups

In this blog i will use Microsoft Active directory  as user Identity source.  in “Active Directory Users and Computers” i created four different groups. The groups will have the same name is the NSX roles to make life easier:

Auditor, Security Administrator, NSX Administrator, Enterprise Administrator.

AD Groups

AD Groups

We create four A/D users and Add each user to different A/D group. for example nsxadmin user:

the user nsxadmin is associate with the group NSX Administrator. the association done by the Add button:

AD user

AD user

Same way i will associate a others users to A/D groups:

username:     groups:

auditor1      ->  Auditor

secadmin ->   Security Administrator

nsxadmin ->  NSX Administrator

entadmin ->  Enterprise Administrator

Connect Directory Domain to NSX Manager.

Go to “Network & Security” tab double click on the “NSX Manager”

map ad to nsx manager role 1

map ad to nsx manager role 1

Double click on “” icon:

map ad to nsx manager role 2

Note: Configure Domain is not needed for RBAC, only if we want to use identity firewall rules base of user or group.

Go to “Manage -> “Domains” -> Click on the green Plus button:

map ad to nsx manager role 8

Fill Name and NetBIOS name fields with appropriate information of your Domain Name and NetBIOS name:

In My example my domain name is corp.local:

map ad to nsx manager role 9

Enter LDAP (i.e AD) IP address or hostname and domain account (username and password):

map ad to nsx manager role 10

Configuring LDAP option task  can be done via direct API call to bypass the Event Log Access described in the next steps).

Click on next.

Event Log Access:

In case we need to create NSX firewall rule with user identity based on AD groups. We will need to allow the NSX Manager read Active Directory “Security Event Log”. This logs contain Active Directory users logon/logoff from to domain. We use this information to bind the AD user  to an IP address.

NSX need access to “Event Log” provide dFW with user identity in one of the two case:

  1. The user logon to VM that doesn’t running VMtools.
  2. The user logon to the domain from PC located on physical environment.

BTW users login to to VM with VMtools up and running , we do not need the “Security Event Log” to bind the user to IP.

Permissions for the user to read logon/logoff events:

Windows 2008 or later domain servers:

Add the account to the Event Log Readers group. If you are using the on-device

User-ID agent, the account must also be a member of the Distributed COM Users Group.


 Windows 2003 domain servers:

Assign Manage Auditing and

Security Logs permissions through group policy

In both of this cases NSX will need to access the AD with read permissions for security event logs, the protocol using to read this information are CIFS or WMI.

During this process NSX  collecting  the following microsoft event ID:

For windows 2008/2012 – Event ID: 4624

For Windows 2003 – Event ID: 540

NSX will “Copy” this Event access log and from A/D and parse the data inside the nsx manager appliance.

map ad to nsx manager role 11

Click Next and Finish:

map ad to nsx manager role 12

Mapping Active Directory  Groups to NSX Managers Roles

Note: This step is must for NSX RBAC to work. 

Now we can map Active Directory groups to pre-built NSX Manager roles.

Go to “Manage -> “Users” -> Click on the green Plus button:

map ad to nsx manager role 3

Here we can select if we want to map specific A/D user to NSX Role or A/D Group to Role.

map ad to nsx manager role 4

In this blog i will use A/D group, we create A/D group called auditor. The format to input here is:

“group_name”@domain.name.  let’s start with auditor group, this group is “Read Only” permission:

map ad to nsx manager role 5

Select one of the NSX Role, for Auditor A/D group we chose Auditor

map ad to nsx manager role 6

We can limit the scope this group can work inside nsx manager object, for this example there is no limit:

map ad to nsx manager role 7

Same way Map all others A/D groups to NSX Roles:

Auditor@corp.local                           – >  Auditor

Security Administrator@corp.local        -> Security Administrator

NSX Administrator@corp.local               -> NSX Administrator

Enterprise Administrator@corp.local     -> Enterprise Administrator

Try our first login with user Auditor1:


 The login successfull but where is the “Network & Security” tab gone ?


So far we configure all NSX Manager part but we didnt take care of the vCenter Configuration permission for that group. are you confusing ?

vCenter has is own Role for each group. we need to configure roles to etch A/D group we configured. These settings determine what the user can make the in vCenter environment.

Configure vCenter Roles:

Let’s start by configure the Auditor Role for Auditor A/D group. we know this group is for “Read Only” in the NSX Manager, so it will make sense to give this group “Read Only” to all other vCenter environment.

Go to vCenter -> Manage -> Permissions and click the green button:

vCenter Roles 1

We need to choose Roles from the Assigned Role, if we select No-Access we will not be able login to vCenter. So we need to choose something from “Read-Only” to “Administrator”

For Auditor Role “Read Only” is the Minimum.

Select “Read Only” from the Assigned Role drop down list and click on the “Add” button from “User and Group”:

vCenter Roles 2

From the Domain Select your Domain name, in our lab the domain is “CORP”, choose your Active Directory group from the list (Auditor for this example) and click the “Add” button:

vCenter Roles 3

Click Ok and Ok for Next Step:

vCenter Roles 4

Same way we need to configure all other groups roles:

vCenter Roles 5

Now we can try to login with auditor1 user:


As we can see auditor1 is in “Read Only” role:


We can  verify that auditor1 can’t change any other vCenter configuration:


Test secadmin user map to “NSX Security” role, this user cannot Change any NSX infrastructure related task like create new  add new NSX Controller Node:


But secadmin can create new firewall rule:


When logging with nsxadmin user map to NSX Administrator Role we can see that the user can add new Controller Node:


But nsxadmin user cannot change or see any firewall rules configure :


What if the user member of two A/D Group ?

The user will gain combined permission access of both of the groups.

For example: the user memberof “Auditor” group and “NSX Security”, the results will be user will have read only permission on all nsx infrastructure and also gain access to all security related area in NSX.


In this post we demonstrate the NSX manager different roles. We configure Microsoft Active Directory as External database source for user’s identity.

Create firewall rules that blocked your own VC

Working on daily tasks with firewalls can sometimes end in a situation where you end up blocking access to the management of your firewall.

This situation is very challenging, regardless of the vendor you are working with.

The end result of this scenario is that you are unable to access the firewall management to remove the rules that are blocking you from reaching the firewall management!


How it’s related to NSX?

Think of a situation where you deploy a distributed firewall into each of your ESX hosts in a cluster, including the management cluster where you have your virtual center located.

And then you deploy a firewall rule like the one below.

Deny any Any Rule

Deny any Any Rule

Let me show you an example of what you’ve done by implementing this rule:

cut tree you sit on

cut tree you sit on

Like the poor guy above blocking himself from his tree, by implementing this rule, you have blocked yourself from managing your vCenter.


How we can we protect ourselves from this situation?

Put your vCenter (and other critical virtual machines) in an exclusion list.

Any VM on that list will not receive any distributed firewall rules.

Go to the Network & security tab Click on NSX Manager

Exclusion VM list 1

Exclusion VM list 1


Double click on the IP address object. In my example it is

Exclusion VM list 2

Exclusion VM list 2

Click on Manage:

Exclusion VM list 3

Exclusion VM list 3

Click on the green plus button.

Exclusion VM list 4

Exclusion VM list 4

Choose your virtual machine.

Exclusion VM list 5

Exclusion VM list 5

That’s it!  Now your VC is excluded from any enforced firewall rules.

Exclusion VM list 6

Exclusion VM list 6


What if we made a mistake and do not yet have access to the VC?

We can use the NSX Manager REST API to revert to the default firewall ruleset.

By default the NSX Manager is automatically excluded from DFW.

Using a REST Client or cURL:


Submit a DELETE request to:


Exclusion VM list 7

After receiving code status 204 we will revert to default DFW policy with default rule to allow.

Exclusion VM list 8

Now we can access our VC, As we can see we revert to default policy, but don’t panic 🙂 , we have saved policy.

Exclusion VM list 9

Click on the “Load Saved Configuration” button.

Exclusion VM list 10

Load Saved Configuration before the last Saved.

Exclusion VM list 11

Accept the warning by click Yes.

Exclusion VM list 12
Now we have our last policy before we blocked our VC.

Exclusion VM list 13

We will need to change the last Rule from Block to Allow to fix the problem.

Exclusion VM list 14

And Click “Publish the Changes”.

Exclusion VM list 15


Exclusion List allows to disable DFW functionality per VM, its Not possible to disable DFW functionality per vNIC

By default NSX Manager, NSX Controllers, Edge Service Gateway and Service VM (PAN FW for instance) automatically excluded from DFW functions

Thank to Michael Moor for reviewing this post