Add a Distributed Firewall

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

The procedure in this topic explains the workflow for adding firewall policies that are applied to the NSX Distributed Firewall or to specific groups with NSX-managed objects.

If your NSX-T Data Center environment has Antrea containers registered to it, you can create Distributed Firewall policies and apply them to Antrea container clusters. For more information, see:

• Distributed Firewall Policies for an Antrea Container Cluster
• Add a Distributed Firewall Policy for Antrea Container Clusters

Note: NSX-T Data Center does not support mixing the rules created with NSX-managed objects and with Antrea container cluster objects in the same Distributed Firewall policy. In other words, the firewall rules that you apply to NSX Distributed Firewall and to Antrea container clusters must be in separate policies.

Prerequisites

Prior to NSX-T Data Center 3.2, VMs must have their vNIC connected to an NSX overlay or VLAN segment to be DFW-protected. In NSX-T Data Center 3.2, distributed firewall protects workloads that are natively connected to a VDS distributed port-group (DVPG). For more information see Distributed Security for vSphere Distributed Switch.

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. When creating a DFW rule using guest instrospection, make sure that the Applied to field applies to the destination group.

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. With admin privileges, log in to NSX Manager.
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. When you change the default, if both the policy level and the rules within have Applied to set to a group, 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. (Optional) If Negate Selections is selected, the rule is applied to traffic coming from all sources except for the sources selected. You can select Negate Selections only if you have at least one source or destination defined. Negated selections are shown with strike-through text.
11. 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.

12. (Optional) If Negate Selections is selected, the rule is applied to traffic going to all destinations except for the destinations selected. You can select Negate Selections only if you have at least one source or destination defined. Negated selections are shown with strike-through text.
13. In the Services column, click the edit icon and select services. The service matches Any if not defined. See Add a Service for more information.
14. 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 Context Profiles for more information.

    Context profiles support the profiles with the attribute type APP ID and Domain (FQDN) Name for use in distributed firewall rules. Multiple context profiles with the attribute type App ID or Domain (FQDN) Name can be used in a distributed firewall rule with services set to Any .

    Context profiles are not supported when creating IDS rules.

15. Click Apply to apply the context profile to the rule.
16. Use Applied to to apply the rule to a selected group. When creating a DFW rule using guest introspection, make sure that the Applied to field applies to the destination group. By default, the Applied To column is set to DFW, and the rule is applied to all workloads. When you change the default, and both the policy level and the rules within have Applied To set to Groups, then 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.
17. 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.
    Jump to Application	Note: This action is only available for the Environment category. Allows the traffic that matches with Environment category rules to continue on for the Application category rules to apply. Use this action when traffic matches with Environment category rules and exits, but you want the Application category rules to apply. For example, if there is an Environment category rule with the action Allow for a specific source and there is an Application category rule with the action Drop for the same source, packets that match the Environment category are allowed through the firewall and further rules are no longer applied. With the Jump to Application action, the packets matches the Environment category rule, but continues on to the Application category rules and the result is that those packets are dropped.

18. Click the status toggle button to enable or disable the rule.
19. 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. Only the first 31 characters in the generated log are supported, although you are able to enter a longer label.

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