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 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 Securing Traffic Within an Antrea Kubernetes Cluster
• Add a Distributed Firewall Policy to Secure Traffic Within an Antrea Kubernetes Cluster

Note: NSX 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

VMs to be DFW-protected must have their vNIC connected to an NSX overlay or VLAN segment. In NSX, 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 host. 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	By default, distributed firewall operates in strict TCP mode. TCP Strict is only applied to stateful TCP rules, and is enabled at the gateway firewall policy level. TCP strict is not enforced for packets that match a default ANY-ANY Allow rule which has no TCP service specified. When 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.
   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. IPv4, IPv6, and multicast addresses are supported. IPv6 firewall must have IP Discovery for IPv6 enabled on a connected segment. For more information, see Understanding IP Discovery Segment Profile.
   See Add a Group.
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. IPv4, IPv6, and multicast addresses are supported.
    See Add a Group.
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.
14. The Context Profiles column is not available when adding a rule to the Ethernet category. For all other rule categories, in the Context Profiles column, click the edit icon and select a context profile, or click Add Context Profile.
    See Context Profiles.

    Context profiles supports profiles with the attribute type APP ID and Domain (FQDN) Name for use in distributed firewall rules. Multiple App ID 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 host.
    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. The maximum number of characters is 39.

20. Click Publish. 1,000 rules in the same section 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.