You can create security policies and DFW rules to apply to multiple locations registered with the Global Manager.

Prerequisites

Ensure that you have already created any customized regions that you want to use for firewall rules. See Create a Region from Global Manager.

Procedure

  1. From your browser, log in with Enterprise Admin or Security Admin privileges to a Global Manager at https://<global-manager-ip-address>.
  2. Select Security > Distributed Firewall
  3. Ensure that you are in the correct pre-defined category, and click Add Policy. For more about categories, see Distributed Firewall.
    Note: Ethernet, Emergency categories and Default Policy are not supported on Global Manager.
  4. Click Add Policy.
  5. Enter a Name for the new policy section.
  6. Click the pencil icon next to Applied To to set the span of this policy.
  7. In the Set Applied To dialog box, you can make the following selections:
    • Region: select which Local Managers to apply the policy to. Each Local Manager is automatically added as a region. You can also create customized regions. See Create a Region from Global Manager.
    • Select Applied To: By default, policy is applied to DFW, that is, the policy is applied to all the workloads on the Local Managers based on the selected region for this policy. You can also apply a policy to selected groups. Applied to defines the scope of enforcement per policy, and is used mainly for resource optimization on ESXi and KVM hosts. It helps in defining a targeted policy for specific zones, tenants and application without interfering with other policy defined for other tenants, zones & applications.

      See DFW Policies and Rules to understand how the span of the policy determines whether your DFW rule is valid or invalid.
  8. 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.

  9. Click Publish. Multiple policies can be added, and then published together at one time.
    The new policy is shown on the screen.
  10. Select a policy section and click Add Rule.
  11. Enter a name for the rule.
  12. The Source and Destination are validated based on the DFW policy's span. See DFW Policies and Rules for more information.

    • If the DFW policy is applied to a location, for example, Loc1, source or destination can be either the keyword ANY or a group that belongs to Loc1.

    • If DFW policy is applied to a user-created region, for example, Region1 source or destination can be either the keyword ANY or a group that has the same span as Region1 or spans a location in Region1.

    • If DFW policy is applied to Global, source or destination can be anything.

    Note: Active Directory and IDFW are not supported for NSX Federation, that is, you cannot use these features from the Global Manager.
    1. In the Sources column, click the pencil icon and select the source of the rule.
    2. In the Destinations column, click the pencil icon and select the destination of the rule. If not defined, the destination matches any.
  13. In the Services column, click the pencil icon and select services. The service matches any if not defined.
  14. In the Profiles column, click the edit icon and select a context profile, or click Add New Context Profile. See Context Profiles.
  15. Click Apply to apply the context profile to the rule.
  16. By default, the Applied to column is set to DFW, and the rule is applied to all workloads. You can also apply the rule or policy to a selected group. Applied to defines the scope of enforcement per rule, and is used mainly for optimization of resources on ESXi and KVM hosts. It helps in defining a targeted policy for specific zones, tenants, and applications without interfering with other policy defined for other tenants and zones and applications.
    Note: You cannot select the following types of groups in Applied-to:
    • a group with IP or MAC addresses
    • an Active Directory user group
  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.
  18. Click the 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 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 appears in the Firewall Log when logging is enabled.
  20. Click Publish. Multiple rules can be added and then published together at one time.
  21. On each policy, click Check Status to view the status of rules it contains, per location. You can click Success or Failed to open the policy status window.
  22. Click Check Status to check the realization status of policies that are applied to Transport Nodes on different locations.