NSX uses firewall rules to specify traffic handling in and out of the network.

Firewall offers multiple sets of configurable rules: Layer 3 rules (General tab) and Layer 2 rules (Ethernet tab). Layer 2 firewall rules are processed before Layer 3 rules and if allowed in the Layer 2 rules will then be processed by the Layer 3 rules. You can configure an exclusion list that contains logical switches, logical ports, or groups that are to be excluded from firewall enforcement.

Firewall Rules are enforced as follows:

  • Rules are processed 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.

No subsequent rules can be enforced as the search is then terminated for that packet. Because of this behavior, it is always recommended to put the most granular policies at the top of the rule table. This will ensure they will be enforced before more specific rules.

The default rule, located at the bottom of the rule table, is a catchall rule; packets not matching any other rules will be enforced by the default rule. After the host preparation operation, the default rule is set to allow action. This ensures that VM-to-VM communication is not broken during staging or migration phases. It is a best practice to then change this default rule to block action and enforce access control through a positive control model (i.e., only traffic defined in the firewall rule is allowed onto the network).
Note: TCP strict can be enabled on a per section basis to turn off mid-session pick-up and enforce the requirement for a three-way handshake. When enabling TCP strict mode for a particular Distributed Firewall Section, and using a default ANY-ANY Block rule, packets that do not complete the three-way handshake connection requirements, and that match a TCP-based rule in this section are dropped. Strict is only applied to stateful TCP rules and is enabled at the distributed firewall section level. TCP strict is not enforced for packets that match a default ANY-ANY Allow which as no TCP service specified.
Table 1. Properties of a Firewall Rule
Property Description
Name Name of the firewall rule.
ID Unique system generated ID for each rule.
Source The source of the rule can be either an IP or MAC address or an object other than an IP address. The source will match any if not defined. Both IPv4 and IPv6 are supported for source or destination range.
Destination The destination IP or MAC address/netmask of the connection that is affected by the rule. The destination will match any if not defined. Both IPv4 and IPv6 are supported for source or destination range.
Service The service can be a predefined port protocol combination for L3. For L2 it can be ether-type. For both L2 and L3 you can manually define a new service or service group. The service will match any, if it is not specified.
Applied To Defines the scope at which this rule is applicable. If not defined the scope will be all logical ports. If you have added "applied to" in a section it will overwrite the rule.
Log Logging can be turned off or on. Logs are stored at /var/log/dfwpktlogs.log file on ESXi hosts.
Action The action applied by the rule can be Allow, Drop, or Reject. The default is Allow.
IP Protocol The options are IPv4, IPv6, and IPv4_IPv6. The default is IPv4_IPv6. To access this property, click the Advanced Settings icon.
Direction The options are In, Out, and In/Out. The default is In/Out. This field refers to the direction of traffic from the point of view of the destination object. In means that only traffic to the object is checked, Out means that only traffic from the object is checked, and In/Out means traffic in both directions is checked. To access this property, click the Advanced Settings icon.
Rule Tags Tags that have been added to the rule. To access this property, click the Advanced Settings icon.
Flow Statistics Read-only field that displays the byte, packet count, and sessions. To access this property, click the graph icon.
Note: If SpoofGuard is not enabled, automatically discovered address bindings cannot be guaranteed to be trustworthy because a malicious virtual machine can claim the address of another virtual machine. SpoofGuard, if enabled, verifies each discovered binding so that only approved bindings are presented.