Layer 7 App IDs are configured as part of a context profile.

A context profile can specify one or more 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 FQDN Filtering 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.

Note:
  • 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 is used in a rule, any traffic coming in from a virtual machine is matched against the rule table based on the 5-tuple. If the rule matching the flow also includes a Layer 7 context profile, the packet is redirected to a user-space component called the vDPI engine. Subsequent packets are sent to the vDPI engine for each flow. After the App ID has been determined, the 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 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 processed in the kernel, and matched against the connection table. For fully matched DROP rules, a reject packet is generated. Logs generated by the firewall will include the Layer 7 App ID and applicable URL, if that flow was sent to the vDPI engine.

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.