Context- aware firewall enhances the visibility at the application level and helps to override the problem of application permeability. Visibility at the application layer helps you to monitor the workloads better from a resource, compliance, and security point of view.

Firewall rules cannot consume application IDs. Context-aware firewall identifies applications and enforces a micro-segmentation for EAST-WEST traffic, independent of the port that the application uses. Context-aware or application-based firewall rules can be defined by defining Layer 7 service objects. After defining Layer 7 service objects in rules, you can define rules with specific protocol, ports, and their application definition. Rule definition can be based on more than 5-tuples. You can also use Application Rule Manager to create context-aware firewall rules.

Context-aware firewall is only supported for NSX for vSphere 6.4 and above.

All clusters in existing NSX managed infrastructure must be upgraded to NSX 6.4, or above.

Types of Firewall

Firewall can take action based on one or a combination of different L2, L3, L4, and L7 packet headers that are added to the data as it moves through each layer of the TCP/IP model.

In layer 3 or layer 4 firewall, the action is taken solely based on source/destination IP, port, and protocol. The activity of network connections is also tracked. This type of firewall is known as a stateful firewall.

Layer 7 firewall is also called as a context-aware firewall. Layer 7 or context-aware firewall can do everything that the layer 3 and layer 4 firewall do. Also, it can intelligently inspect the content of the packets. For example, a layer 7 firewall rule can be written to deny all HTTP requests from a specific IP address.

Rule Definition and Packet Capture

You can create more than 5-tuples rules for context-aware firewall. You can keep adding as many tuples as required to create the correct rule. Protocol and user are the only attributes supported, and you can have either user or protocol per rule. These can be in the standard SRC/DEST fields, or added at the end for extra attributes.

There are 7-tuples in the following rule:













Figure 1. Packet Processing in the Context-Aware Firewall

When a context-aware firewall is configured for the virtual machine, the Distributed Deep Packet Inspection (DPI) attributes must also be matched with the 5-tuples. This is where rules are processed and validated again and the correct rule is found. Depending on the action, a flow is created or dropped.

Here is how a rule is processed for an incoming packet.

  • All the rules are processed normally until a matching context or non-context rule is found. At this stage, only 5-tuples are matched. If the matching rule is a non-context one, the state is attached to it and rule processing is marked as complete.

  • If an L4 part of the context rule is hit, packets are punted to the vDPI process to determine the protocol of the application ID where the flow is already created by the DFW filter. A state is also attached here depending on the movement of the previous packet, which is now marked as DPI under progress.

  • Once the protocol of application ID is determined, the punt is moved to copy mode, where vDPI only observes and sets other attributes only if necessary. Rule revalidation starts here.

  • Because new attributes are discovered though the application ID, the rules must be revalidated beginning from the rule that was attached. This must be done until a similar rule is found, which matches all application ID attributes. Here, the new rule is anchored and an action is taken to accept or drop the packet depending on the action defined in the rule.

It is possible to have a context-aware firewall rule exactly like an L3 or L4 rule, without really defining the context. If that is the case, the validation step might be performed to apply the context, which might have more attributes.

Context-Aware Firewall Workflow