Distributed firewall is a hypervisor kernel-embedded firewall that provides visibility and control for virtualized workloads and networks.
You can create access control policies based on VMware vCenter objects like datacenters and clusters and virtual machine names; network constructs like IP or IPSet addresses, VLAN (DVS port-groups), VXLAN (logical switches), security groups, as well as user group identity from Active Directory. Firewall rules are enforced at the vNIC level of each virtual machine to provide consistent access control even when the virtual machine gets vMotioned.
The NSX Distributed firewall is a stateful firewall, meaning it monitors the state of active connections and uses this information to determine which network packets to allow through the firewall. A flow is identified by the following:
A distributed firewall instance on an ESXi host (one instance per virtual machine vNIC) contains two tables: a rule table to store all policy rules and a connection tracker table to cache flow entries for rules with permit action. DFW rules are enforced in top-to-bottom ordering. Traffic that needs to go through a firewall is first matched against a firewall rules list. 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. The last rule in the table is the DFW default policy rule: packets not matching any rule above the default rule will be enforced by the default rule.
By default, the NSX Distributed Firewall operates in strict TCP mode and when using a default block rule, it drops packets that do not satisfy connection requirements. A connection begins with a three way handshake (SYN, SYN-ACK, ACK) and typically end with a two way exchange (FIN, ACK)
For example, if an IP packet(first packet, pkt1) flow 3, that matches rule number 2 is sent by the VM the following policy lookup and packet flow take place:
Lookup is performed in the connection tracker table to check if an entry for the flow already exists
Because 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 matches the flow will be enforced.
Rule 2 matches flow 3.
Because the Action is set to ‘Allow’ for flow 3, a new entry will be created inside the connection tracker table. The packet is then transmitted out of the distributed firewall.
Flows are dropped when the packet sequence number is out of sync
For L2 packets, distributed firewall creates a cache for performance boost. L3 packets are processed in the following sequence:
All packets are checked for an existing state. This is done for SYNs too so that bogus or retransmitted SYNs for existing sessions can be detected.
If a state match is found, the packets are processed.
If a state match is not found, the packet is processed through the rules until a match is found.
For TCP packets, a state is set only for packets with a SYN flag. However, rules that do not specify a protocol (service ANY), can match TCP packets with any combination of flags.
For UDP packets, 5-tuple details are extracted from the packet. If a state does not exist in the state table, a new state is created using the extracted 5-tuple details. Subsequently received packets are matched against the state that was just created.
For ICMP packets, ICMP type, code, and packet direction are used to create a state.
Distributed firewall can help in creating identity-based rules as well. Administrators can enforce access control based on the user's group membership as defined in the enterprise Active Directory. Here are some scenarios where identity-based firewall rules can be used:
User accessing virtual applications using a laptop or mobile device where AD is used for user authentication
User accessing virtual applications using VDI infrastructure where the virtual machines are Microsoft Windows based
If you have a third-party vendor firewall solution deployed in your environment, see Redirecting Traffic to a Vendor Solution through Logical Firewall.
Running open VMware Tools on guest or workload virtual machines has not been validated with distributed firewall.