Edit

Share via

Object Model

  • Article

The following table lists the object types that can be manipulated through the various API sets supplied by the Windows Filtering Platform (WFP).

Object Type Description Sample Properties Example
Filter A rule that governs classification. If the conditions are met, the action is invoked.
This is the most complex object exposed by WFP since it ties together all the other object types.
  • Array of conditions
  • Action (Permit, Block, Callout)
  • Weight
  • Context
 "Block traffic with a TCP port greater than 1024."
"Callout to IDS for all traffic that is not secured."
Callout A set of functions that participate in the classification process.
It allows for custom packet processing to be done when certain conditions are met.
  • ID
  • Applicable layer
 The NAT driver
Layer A filter container in the filter engine.
Represents a specific point in network traffic processing where the filter engine is invoked.
  • Schema for filters that can be added to the layer
 The Inbound Transport Layer
Sub-layer A sub-component of a layer, used in filter arbitration.
  • Weight
 The IPsec Tunnel sub-layer
Provider A policy provider that has built a solution on WFP.
It is used solely for management; it does not affect run-time packet processing.
  • ID
  • Service name
 Windows Firewall with Advanced Security
A 3rd-party URL filtering application
Provider Context A data blob used by a policy provider to store arbitrary context information.
It is used to pass custom configuration information to a callout.
The most common way to use the context information is to have filters reference a provider context.
  • ID
  • Data blob
 IPsec stores authentication settings in the Base Filtering Engine ( BFE). The "Context" property of a filter indicates the authentication settings to use for the traffic that the filter describes.
The SSL certification selection shim will store certification information in a provider context.

The object types exposed by WFP API have consistent semantics. The actions of add, enumerate, subscribe, and so on are similar for all object types.

Each object type is represented by a data structure (for example, FWPM_FILTER0). In order to minimize the number of different data structures exposed by the WFP API, the same data structure is used for both adding new objects and retrieving existing ones. Thus, there may be fields in each data structure that are ignored when adding a new object since these fields are filled in by the Base Filtering Engine (BFE), and not by the caller. For example, an FWPM_FILTER0 data structure has a filterId field that contains the LUID of the corresponding FWPS_FILTER0. This LUID is assigned by BFE, and thus, this field is ignored in the call to FwpmFilterAdd0.

Object Management