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 running in the NSX VPC.
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.
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 policy in an NSX VPC:
ORG-default PROJECT-<Project_Name> VPC-<VPC_Name> default-layer3-sectionProject_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.
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.
- Rule 1033 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 1034 allows all DHCP traffic. You can modify this default rule, if required.
- Rule 1035 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. It contains only a single firewall rule.
The firewall 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. However, you can add custom N-S firewall rules to restrict incoming or outgoing traffic depending on your security requirements.
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.
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.
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.
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.
- 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.
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.
To allow incoming traffic from outside the NSX VPC to reach workloads on the private subnets, do the following steps:
- Ensure that N-S Services option is turned on for the NSX VPC.
- 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.
- 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