When I first started using NSX I ran into this little problem. What does apply to mean and how should I use it?
Background
I believe the background for the apply to is from physical firewalls. They allowed you to apply rules to a specific interface. Applying to an interface had the following effects:
- Limit the number of rules that have to be processed
- Allow specific fine-grained controls
Applying rules to specific interfaces had a few issues:
- You had to have a good understanding of the network topology in order apply rules correctly
- New interfaces may be missed by rules
You also had the ability to apply the rule to all interfaces that existed. On the surface if you had enough hardware to apply the rules everywhere it worked great. Tons of interfaces who didn’t need the rules now had them. There are a few problems:
- New interfaces would have no rules and all rules would have to be applyed to them
- These rules exist only on a single firewall rule creation is specific to that firewall
NSX Firewall
The NSX firewall takes a similar approach to firewall application. All firewall rules are created in NSX manager and stored inside the NSX manager database. By default rules are applied to the “distributed firewall”. This will apply the rules to all virtual machines vNIC, regardless of the virtual machines location. This creates the same problem as applying on every interface, each vNIC will have a long list of rules to attempt to match.
This is where the apply to tag becomes interesting. In order to explain I’ll use a simple example:
Two virtual machines: 172.16.0.2 on VNI 5000 and 172.16.20.2 on VNI 5002.
My default firewall rule set allows them to communicate without any issues. Let assume I want to block all traffic between these machines so I create the following rule:
Source: 172.16.0.2 virtual machine
Destination: 172.16.20.2 virtual machine
Service: Any
Action: Block
Apply to: Distributed firewall (default)
Using Traceflow we can identify where it was blocked:
You can see clearly the default of distributed switch applied the drop action to the source. This is really great because it limits the traffic on the physical wire. Since the object is known as a managed object in NSX the rule is enforced as soon as possible. If you have a physical entity that is not managed by NSX the rule will be applied upon the destination. This is hard to prove because traceflow cannot provide visibility to physical entities.
What does apply to do?
Simply put it tells NSX where to apply the firewall rule. Lets examine some of the options for my rule above:
- Host
- Cluster
- Virtual machine
- IP or Mac set
- etc..
It provides the full list of objects that DFW rules can made with including dynamic sets and tags. This is really powerful. For the sake of this example lets apply the rule to the destination virtual machine instead of the DFW.
Using traceflow we can see the results:
My attempted connection was dropped at the destination where I applied the firewall rule. You can also see how it between 7 and 8 the message left host 3 and went across my physical network to host 1 (black hole of visibility)
Why use the apply to feature?
- Reduce the amount of rules applied to each vNIC
- Enforce the rule at a specific location (think situations with VM overlap or rule overlap)
Apply to does add to the complexity of the environment and troubleshooting but can limit scope. This is where careful planning and understanding of the environment can really help. Arkin can help as well but that’s another days post.
