Distributed firewall monitors all the East-West traffic on your virtual machines.

Prerequisites

To be DFW-protected, VMs must have their vNIC connected to an NSX overlay or VLAN segment.

If you are creating rules for Identity Firewall, first create a group with Active Directory members. To view supported protocols for IDFW, see Identity Firewall Supported Configurations.
Note: For Identity Firewall rule enforcement, Windows Time service should be on for all VMs using Active Directory. This ensures that the date and time is synchronized between Active Directory and VMs. AD group membership changes, including enabling and deleting users, do not immediately take effect for logged in users. For changes to take effect, users must log out and then log back in. AD administrator's should force a logout when group membership is modified. This behavior is a limitation of Active Directory.

Note that if you are using a combination of Layer 7 and ICMP, or any other protocols you need to put the Layer 7 firewall rules last. Any rules after a Layer 7 any/any rule will not be executed.

For Federation-specific details on distributed firewall policy and rule creation, see Create DFW Policies and Rules from Global Manager.

Procedure

  1. From your browser, log in with admin privileges to an NSX Manager at https://<nsx-manager-ip-address>.
  2. Select Security > Distributed Firewall from the navigation panel.
  3. Ensure that you are in the correct pre-defined category, and click Add Policy. For more about categories, see Distributed Firewall.
  4. Enter a Name for the new policy section.
  5. (Optional) Use Applied to to apply the rules within policy to a selected group. By default, the policy Applied to field is set to DFW, and the policy rules are applied to all workloads. The policy level Applied to takes precedence over Applied to at the rule level.
    Note: Groups consisting of only IP addresses, MAC Addresses, or Active Directory groups cannot be used in the Applied To text box.

    Applied to defines the scope of enforcement per policy, and is used mainly for optimization of resources on ESXi and KVM hosts. It helps in defining a targeted policy for specific zones, tenants or applications, without interfering with other policy defined for other applications, tenants and zones.

  6. (Optional) To configure the following policy settings, click the gear icon:
    Option Description
    TCP Strict A TCP connection begins with a three-way handshake (SYN, SYN-ACK, ACK) and typically ends with a two-way exchange (FIN, ACK). In certain circumstances, the distributed firewall (DFW) might not see the three-way handshake for a particular flow ( due to asymmetric traffic or the distributed firewall being enabled while a flow exists). By default, the distributed firewall does not enforce the need to see a three-way handshake, and picks up sessions that are already established. 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 DFW policy, 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 policy level. TCP strict is not enforced for packets that match a default ANY-ANY Allow which has no TCP service specified.
    Stateful A stateful firewall monitors the state of active connections and uses this information to determine which packets to allow through the firewall.
    Locked The policy can be locked to prevent multiple users from editing the same sections. When locking a section, you must include a comment.

    Some roles such as enterprise administrator have full access credentials, and cannot be locked out. See Role-Based Access Control.

  7. Click Publish. Multiple policies can be added, and then published together at one time.
    The new policy is shown on the screen.
  8. Select a policy section and click Add Rule, and enter a rule name.
  9. In the Sources column, click the edit icon and select the source of the rule. Groups with Active Directory members can be used for the source text box of an IDFW rule. See Add a Group for more information.
    IPv4, IPv6, and multicast addresses are supported.

    Note: IPv6 firewall must have IP Discovery for IPv6 enabled on a connected segment. For more information, see Understanding IP Discovery Segment Profile.

  10. In the Destinations column, click the edit icon and select the destination of the rule. If not defined, the destination matches any. See Add a Group for more information.
    IPv4, IPv6, and multicast addresses are supported.
  11. In the Services column, click the edit icon and select services. The service matches Any if not defined.
  12. The Profiles column is not available when adding a rule to the Ethernet category. For all other rule categories, in the Profiles column, click the edit icon and select a context profile, or click Add New Context Profile. See Add a Context Profile.
    Context profiles use layer 7 APP ID attributes for use in distributed firewall rules and gateway firewall rules. Multiple App ID context profiles can be used in a firewall rule with services set to Any. For ALG profiles (FTP, or TFTP), one context profile is supported per rule.
    Context profiles are not supported when creating IDS rules.
  13. Click Apply to apply the context profile to the rule.
  14. Use Applied to to apply the rule to a selected group. By default, the Applied To column is set to DFW, and the rule is applied to all workloads. If both policy and the rules within have Applied to set to a group, then policy level Applied to takes precedence over Applied to at the rule level.
    Note: Groups consisting of only IP addresses, MAC Addresses, or Active Directory groups cannot be used in the Applied To text box.
  15. In the Action column, select an action.
    Option Description
    Allow Allows all L3 or L2 traffic with the specified source, destination, and protocol to pass through the current firewall context. Packets that match the rule, and are accepted, traverse the system as if the firewall is not present.
    Drop Drops packets with the specified source, destination, and protocol. Dropping a packet is a silent action with no notification to the source or destination systems. Dropping the packet causes the connection to be retried until the retry threshold is reached.
    Reject Rejects packets with the specified source, destination, and protocol. Rejecting a packet is a more graceful way to deny a packet, as it sends a destination unreachable message to the sender. If the protocol is TCP, a TCP RST message is sent. ICMP messages with administratively prohibited code are sent for UDP, ICMP, and other IP connections. One benefit of using Reject is that the sending application is notified after only one attempt that the connection cannot be established.
  16. Click the status toggle button to enable or disable the rule.
  17. Click the gear icon to configure the following rule options:
    Option Description
    Logging Logging is turned off by default. Logs are stored at /var/log/dfwpktlogs.log file on ESXi and KVM hosts.
    Direction 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 that traffic in both directions is checked.
    IP Protocol Enforce the rule based on IPv4, IPv6, or both IPv4-IPv6.
    Log Label

    Log Label is carried in the Firewall Log when logging is enabled.

  18. Click Publish. Multiple rules can be added and then published together at one time.
  19. The data path realization status of policy with Transport Nodes details shown on the right side of the policy table.