Layer 7 Ap Ids are configured as part of a context profile.

A context profile can specify one or more Attributes (App IDs), and can also include sub-attributes, for use in distributed firewall (DFW) rules and gateway firewall rules. When a sub-attribute, such as TLS version 1.2 is defined, multiple application identity attributes are not supported. In addition to attributes, DFW also supports a Fully Qualified Domain Name (FQDN) or URL that can be specified in a context profile for FQDN allowlisting or denylisting. See Filtering Specific Domains (FQDN/URLs) for more information. FQDNs can be configured with an attribute in a context profile, or each can be set in different context profiles. After a context profile has been defined, it can be applied to one or more distributed firewall rules.

  • Gateway firewall rules do not support the use of FQDN attributes or other sub attributes in context profiles.
  • Context profiles are not supported on tier-0 gateway firewall policy.

When a context-profile has been used in a rule, any traffic coming in from a virtual machine is matched against the rule-table based on 5-tuple. If the rule matches the flow also includes a Layer 7 context profile, that packet is redirected to a user-space component called the vDPI engine. A few subsequent packets are punted to that vDPI engine for each flow, and after it has determined the App Id, this information is stored in the in-kernel context-table. When the next packet for the flow comes in, the information in the context table is compared with the rule table again and is matched on 5-tuple, and on the layer 7 App Id. The appropriate action as defined in the fully matched rule is taken, and if there is an ALLOW-rule, all subsequent packets for the flow are process in the kernel, and matched against the connection table. For fully matched DROP rule a reject packet is generated. Logs generated by the firewall will include the Layer 7 App Id and applicable URL, if that flow was punted to DPI.

Rule processing for an incoming packet:
  1. Upon entering a DFW or Gateway filter, packets are looked up in the flow table based on 5-tuple.
  2. If no flow/state is found, the flow is matched against the rule-table based on 5-tuple and an entry is created in the flow table.
  3. If the flow matches a rule with a Layer 7 service object, the flow table state is marked as “DPI In Progress.”
  4. The traffic is then punted to the DPI engine. The DPI Engine determines the App Id.
  5. After the App Id has been determined, the DPI Engine sends down the attribute which is inserted into the context table for this flow. The "DPI In Progress" flag is removed, and traffic is no longer punted to the DPI engine.
  6. The flow (now with App Id) is reevaluated against all rules that match the App Id, starting with the original rule that was matched based on 5-tuple, and the first fully matched L4/L7 rule is picked up. The appropriate action is taken (allow/deny/reject) and the flow table entry is updated accordingly.