When an NSX VPC is realized successfully, the system creates default north-south and east-west firewall rules to govern the default firewall behavior for the workloads in the NSX VPC.

Overview

N-S firewall rules are centralized rules that apply to traffic going in and out of the NSX VPC.

E-W firewall rules are distributed rules that apply to workloads running inside the NSX VPC.

The firewall rules in an NSX VPC apply only to the VMs in the VPC. That is, VMs that are connected to the subnets in the NSX VPC. The firewall rules in a NSX VPC do not impact workloads outside the VPC.

In the following subsections, the term "base license" refers to any of the following two licenses:

  • NSX Networking for VMware Cloud Foundation
  • Solution License for VCF
East-West Firewall

The base license entitles the system to only the networking features. You cannot configure the east-west firewall security feature in an NSX VPC. To add or edit E-W firewall rules in an NSX VPC, you must apply an appropriate security license in the system.

If a security license is not applied, the system-created default E-W firewall rules are not activated in the NSX VPC. The default E-W rules exist in the NSX VPC, but they are inactive in the NSX VPC. You cannot edit the default E-W rules and neither you can activate them in the NSX VPC.

North-South Firewall

The base license entitles the system to add or edit only stateless N-S firewall rules in an NSX VPC. To add or edit both stateful N-S firewall and stateless N-S firewall rules in an NSX VPC, you must apply an appropriate security license in the system.

The default N-S firewall policy in an NSX VPC is a stateful policy. When a security license is not applied in the system, you can edit only the rule action of the default N-S firewall rule. No other edits are allowed in the default rule. You cannot change the state of the default N-S firewall policy from stateful to stateless.

Default East-West Firewall Rules in an NSX VPC

For each NSX VPC that is added in the project, the system creates a default E-W firewall policy in the NSX VPC. The following naming convention is used to identify the default E-W firewall policy in an NSX VPC:

PROJECT-<Project_Name> VPC-<VPC_Name>-default-layer3-section

Project_Name and VPC_Name are replaced with actual values in the system.

For example, the following screen capture shows the default E-W firewall rules in an NSX VPC.


This image is described in the surrounding text.

All three default E-W firewall rules in an NSX VPC have the Applied To set to DFW. Although the Applied To is set to DFW, the firewall rules are enforced only on the workload VMs that are connected to the subnets in the NSX VPC. Workload VMs that are outside the NSX VPC are not impacted by these firewall rules. If required, VPC users can set the Applied To as Groups, and select only those groups that are created in the NSX VPC.

Let us understand the meaning of the three default E-W rules, as seen in this screen capture:
  • Rule 1030 allows all outgoing traffic from the subnets in the NSX VPC. The destination of the outgoing traffic can be workloads within the NSX VPC or outside the VPC. You can modify this default rule, if required.
  • Rule 1031 allows all DHCP traffic. You can modify this default rule, if required.
  • Rule 1032 drops all traffic that does not match the previous two rules. This rule implicitly means that all incoming traffic to the NSX VPC is dropped, by default. You can modify only the rule action of this default rule. All other fields in this rule are not editable.

Default North-South Firewall Rule in an NSX VPC

For each NSX VPC that is added in the project, the system creates a default N-S firewall policy in the NSX VPC. For example, the following screen capture shows the default N-S policy in an NSX VPC, which is a stateful policy. It contains only a single firewall rule.


This image is described in the surrounding text.

The rule allows all traffic through the VPC N-S firewall, by default. You can modify only the rule action of this default rule. All other fields in this rule are not editable.

As mentioned earlier in the Overview section of this documentation, the base license entitles the system to add or edit only stateless N-S firewall rules in an NSX VPC. To add or edit both stateful N-S firewall and stateless N-S firewall rules in an NSX VPC, you must apply an appropriate security license in the system.

Communication Within an NSX VPC

By default, east-west traffic between workloads within an NSX VPC is allowed.

For example, the following diagram shows three workload VMs in an NSX VPC. By default, VM 1 on the public subnet can communicate with VM 2 on the private subnet in either direction.

By default, VMs on isolated subnets cannot communicate to VMs on private or public subnets. However, in this diagram VM 2 on the private subnet is also connected to the isolated subnet. Therefore, VM 2 on the private subnet can communicate with VM 3 on the isolated subnet in either direction.


Diagram is described in the surrounding text.

Egress Communication from an NSX VPC

As explained earlier in this topic, all outgoing traffic from an NSX VPC is allowed, by default.

Workloads that are connected to public subnets can send packets outside the NSX VPC regardless of whether the N-S Services option is turned on or off for the NSX VPC. The workloads on public subnets are assigned IP addresses from the external IPv4 blocks of the NSX VPC. The external IP addresses are reachable outside the NSX VPC.

Workloads that are connected to private subnets can send packets outside the NSX VPC only when the following conditions are met:

  • The N-S Services option is turned on for the NSX VPC.
  • The Default Outbound NAT option is turned on for the NSX VPC.

When the Default Outbound NAT option is turned on, a default SNAT rule is created for the NSX VPC to allow traffic from the workloads on the private subnet to be routed outside the NSX VPC. On similar lines, if this option is turned off, the default SNAT rule is not created, and traffic from the private subnets cannot be routed outside the NSX VPC.

For example, the following diagram shows an NSX VPC on which Default Outbound NAT is turned off. Traffic from VM 1 on the public subnet can go directly to user 1.1.1.1, which is outside the NSX VPC. However, egress traffic from VM 2 on the private subnet is blocked.


Diagram is described in the surrounding text.

The following diagram shows an NSX VPC on which Default Outbound NAT option is turned on. In this case, the system automatically configures a default SNAT rule on the N-S firewall of the VPC. The IP address of VM 2 on the private subnet is translated to an external IP, which is allocated by the system from the external IPv4 block. VM 2 on the private subnet can now send traffic to user 1.1.1.1 that is outside the NSX VPC. VM 1 on the public subnet can continue to send traffic outside the NSX VPC without going through NAT on the VPC N-S firewall.


Diagram is described in the surrounding text.

Ingress Communication into an NSX VPC

As mentioned earlier in this topic, the default E-W rule (rule 1035) drops all incoming traffic to the NSX VPC.

Incoming traffic to the NSX VPC can be any of the following traffic:
  • Traffic coming from workloads running in other NSX VPCs that are either in the same project or a different project.
  • Traffic coming from workloads running on any network within the data center.
  • Traffic coming from the Internet.

For example, the following diagram shows that traffic from user 1.1.1.1, which is connected to a tier-0/VRF gateway, is blocked from reaching VM 1 on the public subnet and VM 2 on the private subnet.


Diagram is described in the surrounding text.

To enable incoming traffic from outside the NSX VPC to reach the workloads on the public subnets, you will need to add a custom E-W firewall policy or modify the E-W rule in the default firewall policy of the NSX VPC. Remember that the default N-S rule in the NSX VPC allows all traffic through the VPC N-S firewall, by default.

Note: We recommend VPC users to add custom N-S firewall rules in their NSX VPC to restrict incoming traffic only to specific ports depending on their security requirements.

To allow incoming traffic from outside the NSX VPC to reach workloads on the private subnets, do the following steps:

  1. Ensure that the N-S Services option is turned on for the NSX VPC.
  2. Add a NAT rule with either reflexive action or DNAT action in the NSX VPC.

    In the NAT rule, allocate a valid IPv4 address from the external IPv4 block so that the system can map the VM IP address on the private subnet to this external IPv4 address. For instance, if you are creating a NAT rule with reflexive action, specify the external IPv4 address in the Translated IP text box of the rule definition. The IPv4 address must belong to the external IPv4 block of the NSX VPC and it must be available for allocation, otherwise an error message is displayed. Currently, in the Translated IP text box, only a single IPv4 address is supported. A CIDR block is not supported.

    Do this step to enable ingress traffic for each workload VM that is attached to the private subnet. For example, if four workload VMs are attached to the private subnet, create four separate NAT rules.

  3. Add a custom E-W firewall policy or modify the E-W rule in default firewall policy of the NSX VPC to allow traffic to reach the workloads on the private subnets.

After completing these steps, all incoming traffic is now allowed on the workloads of the private subnets. As mentioned in the previous subsection, we recommend VPC users to add custom N-S firewall rules in their NSX VPC to restrict incoming traffic to specific ports depending on their security requirements.

For example, the following diagram shows that traffic from user 1.1.1.1, which is connected to a tier-0/VRF gateway, goes through NAT on the VPC N-S firewall, and then reaches VM 2 on the private subnet.

In this example, the NAT rule configuration is as follows:

  • Source IP: 10.5.0.5 (private IP address of VM 2)
  • Translated IP: 5.5.100.100 (IP address from the external IPv4 address block that is allocated to VM 2)
  • Action: Reflexive

Diagram is described in the surrounding text.