A Conversation About Different Types of Catch-All Rules While Implementing vDefend Distributed Firewall
CuriousTechie: Hello IT Guy! I’m starting a project to implement micro-segmentation using vDefend Distributed Firewall (DFW) for applications running in my SDDC environment. I’ve read that I need to implement Catch-All rules to analyze traffic. Can you help me understand what these rules actually mean and how they should be built?
ITGuy: Let’s start with the basic. Firewalls are generally implemented using two major approaches:
- Allow List – You explicitly create ALLOW rules for known, required (good) traffic.
- Block List – You explicitly create DROP rules for known, unwanted (bad) traffic.
When you micro-segment an application, you typically need to build ALLOW rules for all required (known) traffic for the application to function properly. At the end of these ALLOW rules, you usually place a DROP rule to block all unwanted or unknown traffic.
However, In brownfield environments, teams often lack complete visibility into all application dependencies. Enforcing a default DROP rule prematurely, without sufficient traffic analysis, can therefore result in unintended application outages.
To address this challenge, a Catch-All rule is implemented to monitor and log traffic that does not match any existing ALLOW rules, enabling teams to identify missing dependencies before enforcing restrictive security controls.
In simple terms, a Catch-All rule is a temporary monitoring rule placed at the bottom of an application-specific Distributed Firewall policy to observe traffic that is not yet explicitly allowed. This rule is typically configured in ALLOW mode with logging enabled during the discovery phase, prior to enforcing a strict default DROP posture.
CuriousTechie: How does the Catch-All rule help monitor traffic? What tools can be used for this analysis?
ITGuy: When traffic hits the Catch-All rule, it indicates that no explicit ALLOW rule has yet been defined for that specific flow. If that traffic is required for the application, a corresponding ALLOW rule must be created above the Catch-All rule.
At a high level, there are three ways to monitor traffic hitting Catch-All rules:
- Use Security Intelligence(Preferred) – Security Intelligence is a feature running on the Security Services Platform (SSP) that provides visibility into traffic flows across the environment and generates data-driven Distributed Firewall rule recommendations, while maintaining centralized policy governance.
- Use VCF Operations for Networks (formerly vRNI, also known as AON) – This tool can be used to analyze flows passing through a particular DFW rule ( the Catch-All ). Required rules can then be created manually or using other preferred method.
- Use VCF Operations for Logs (formerly vRLI, also known as AOL)– VCF Operations for Logs is best suited for verification and deep-dive troubleshooting rather than initial dependency analysis, as packet-level inspection can be time-intensive and operationally complex.
CuriousTechie: Should I create two Catch-All rules for Ingress and Egress, or use a single rule and just use the Applied To field?
ITGuy: Excellent question! Let’s look at the differences between these two approaches.
Option 1: Use separate rules for ingress and Egress
This approach can be useful when you are manually analyzing flows, as having two separate rules allows you to focus on ingress and egress traffic independently. It can provide some operational convenience.
However, there are a few challenges with this approach:
- The Catch-In rule does not capture multicast or broadcast traffic targeting the vNIC, which can result in incomplete visibility during the discovery phase.
- When using Security Intelligence, traffic hitting ingress and egress Catch-All rules is classified as Protected, which means it is treated as intentionally permitted and is therefore excluded from recommendation analysis.
Option 2: Use a Single Catch-All Rule
This is the recommended and default approach for modern implementations using Security Intelligence.
This method overcomes the limitations of the previous approach by capturing all traffic hitting the vNIC of virtual machines that are members of the group specified in the Applied To field.
Traffic flowing through a single Catch-All rule is classified as Unprotected, making it eligible for Security Intelligence analysis and rule recommendation generation.
Catch-All rules should be time-bound and periodically reviewed, with the objective of replacing them with explicit ALLOW rules and ultimately enforcing a default DENY posture in alignment with zero-trust principles.
CuriousTechie: This is great information! I’ll plan to use the single Catch-All rule approach.. But I am very curious to understand:
- Why is multicast and broadcast traffic not captured by the Catch-In rule in the first scenario?
- What exactly do Protected and Unprotected traffic mean in Security Intelligence?
ITGuy: Great questions! Let’s dive into these topics the next time we talk!
Curious-Techies 