NSX DFW Firewall Rules - WAN Outbound

[CFCSpath]

What are the best practices or perhaps someone could share some examples of how to implement DFW Rules for Outbound External Traffic?

• All of the reference material that I have extensively reviewed discusses at length how one would implement security policies on the distributed firewall for micro-segmentation purposes.

• The one aspect that appears to be omitted everywhere is the fact that segmented work-loads often require internet access, or the ability to send requests to "any internet destinations" to an ESG for example.

• If one would want to leverage a zero trust model (with an explicit "any any deny") in their distributed firewall policy, what are some of the best strategies to ensure that certain work-loads can send outbound traffic Northbound?

This question is more or less the reverse of Duplicate rules when using ESG and DFW

Taking Add a Universal Firewall Rule as a referenced example, the appropriate rule is in place to allow traffic from "any" to the appropriate services of "Web USG". No rules appear in this example of the correct best practice should "Web USG" require communicating to the outside.

Would you create an IP Set with RFC1918 addresses and then negate those addresses in the destination?

Or is it better to use direction, considering that having a rule including both directions would most likely create undesirable results?

• Source: SG1 / Destination: Any / Service: Any / Action: Allow / Direction: Out
• Source: SG2 / Destination: Any / Service: Any / Action: Allow / Direction: Out

[cnrz]

NSX Edge Firewall is generally used for N-S traffic, i.e. traffic going out (or coming in) from the NSX environment. Dfw generally is used for E-W traffic, which is the traffic within the NSX environment, but the rules may include N-S traffic or Internet traffic as well as it is deployed at the VM vnic level.

For Internet access, generally it may be a best practice to group the VMs that will have internet access allowed. This could be grouping as an IP Set, VM group or attaching a certain Tag for example "internet".  The source SG_Internet_VMs to destination IP any allow service http/https.

There could be two ways for internet traffic matching as this link could be helpful:

NSX rule to represent internet traffic

You would actually create 2 firewall rules, but in a different order. As firewall rules are in a 'first match, first served' basis, you'd want to block the internal traffic first and then allow traffic to the internet. There's no real distinction for the 'internet', as it's all just IP subnets. Here's what it would look like:

1. Block all to 172.16.x.x/10.x.x.x/192.168.x.x (the martian networks and any and all other internal IP subnets you're using for internal use)

2. Allow to 0.0.0.0/0

If your policy has a default deny rule, you can do it in a single rule.

Create a Security Group or IP Set that contains all your "internal" networks and use this in the destination of your allow rule, but make sure you negate the rule.

Universal rules are dFW rules that are replicated across NSX Managers with Cross-vCenter solution. If Cross-vCenter is used, it is useful for centrally managing Internet rules centrally. For a single Site solution global rules instead of Universal could be used.

If the VMs on the Source group is dynamically provisioned, it is not difficult to maintain Internet rules on both Edge and dFW for the Zero Trust Microsegmentation model, although seems more overhead.

[Sree]

In general for DC network  traffic , we should do first level of filtering at physical firewall followed by filtering at Edge level( A-S deployment) for NAt/Load balanced traffic etc and last level of chain using DFW policy. For wan/Internet traffic most of the time advanced level of traffic check will be required which demands traffic steering to third party appliances via DFW  . From my experience , i haven't seen anyone offloading full firewall functionality to Edges/DFW - ideal solution is to use firewall rules at both the places(Like i have mentioned earlier). So to keep it simple and clean, DFW for E-W traffic and Edges and Physical Firewall for N-S is one way of doing. Another approach would be DFW for N-S and E-W traffic if Edges are in ECMP with Physical Firewall still doing advanced traffic monitoring for N-S traffic in addition we can have traffic steering to third party virtual appliances via DFW.