Skip to main content

Layer-7 User-Group Filtering

User-group and user-ID filters let you query how the network handles specific traffic when that traffic is generated by a user indicated in the query. This is useful for validating identity-based firewall policies — for example, confirming that members of a contractor group cannot reach internal finance servers, or verifying that a specific user's traffic is routed through the correct inspection chain.

info

Forward does not automatically map source IP addresses to user groups. You must specify the relevant groups in your query. The system assumes the groups you provide are the complete set for that user.

How It Works​

When you include user_group_id or user_id in a query, Forward evaluates firewall rules that match on those identity attributes. The system resolves user-group memberships internally (mapping groups to individual user IDs) and applies the resulting identity context when traversing policies along the path.

  • user_group_id — specifies which group(s) the source user belongs to
  • user_id — specifies a single user identity

Both fields can only appear after from(). See Layer-7 / Application Filters for the general restriction.

Query Examples​

No user group specified​

from(10.1.0.5)(ipv4_dst.10.2.0.10) z(delivered)

Without a user-group filter, the system skips user-group clauses in firewall rules — they neither permit nor deny traffic. If a rule along the path does contain a user-group match, the filter panel still shows which groups were referenced, giving you visibility into which identities are involved in policy decisions along the path.

Single user group​

from(10.1.0.5)(user_group_id.GroupA)(ipv4_dst.10.2.0.10) z(delivered)

The system traces paths under the assumption that the source user belongs only to GroupA. If GroupA is sufficient to reach the destination, delivered paths are returned. If GroupA is denied, no delivered results appear.

If a firewall rule along the path requires membership in a different group (GroupB), the system checks whether any user exists who belongs to both GroupA and GroupB. If such a user exists, traffic is delivered; if not, traffic is denied. The filter panel and sample packet reflect which groups were required.

Multiple user groups​

from(10.1.0.5)(user_group_id.GroupA)(user_group_id.GroupB)(ipv4_dst.10.2.0.10) z(delivered)

Multiple groups are treated as an intersection: the query models a user who belongs to all specified groups. The system computes which user IDs are members of every listed group and evaluates policies against that intersection.

If the specified groups have no common members, the query returns no results.

User ID​

from(10.1.0.5)(user_id.jsmith)(ipv4_dst.10.2.0.10) z(delivered)

User-ID queries work like user-group queries but target a specific individual. The system resolves the user's group memberships and evaluates policies accordingly.

note

Only one user_id value can be specified per query. To analyze multiple users, run separate queries.

Combining user ID and user group​

You can include both user_id and user_group_id in the same query. The system intersects the specified user's memberships with the specified groups — effectively asking "what happens when this user, as a member of these specific groups, sends traffic?"

Incomplete or Incorrect Group Lists​

Because Forward relies on you to provide the group list, specifying an incomplete or incorrect set changes the results. A user often belongs to multiple groups, and firewall rules may match on any of them:

Overlapping user-group membership

Missing a required group​

  • Scenario: User belongs to GroupA and GroupB. Firewall requires GroupB. You query with only GroupA.
  • Result: No delivered paths are returned, even though the real user's traffic would be delivered.
  • Why: The system treats GroupA as the user's only group membership. Since the firewall requires GroupB and GroupA alone does not satisfy that rule, traffic is denied.

To investigate, remove the z(delivered) outcome filter and inspect where and why traffic is stopped.

note

A query scoped to GroupA that returns no delivered paths does not prove that GroupA members cannot reach the destination. A user in GroupA may also belong to other groups that grant access.

Missing a deny group​

  • Scenario: User belongs to GroupA and GroupC. A firewall deny rule matches GroupC, followed by a permit rule matching GroupA. You query with only GroupA.
  • Result: Delivered paths may be returned even though the real user's traffic would be denied by the GroupC rule.
  • Why: The system is unaware of the GroupC membership and does not evaluate the deny rule.

Overlapping but disjoint groups​

  • Scenario: User belongs to GroupA and GroupC. You query with GroupA and GroupB. A firewall rule requires GroupC.
  • Result: No results. The system first computes the intersection of GroupA and GroupB members (from the query), then checks whether any user in that set is also a member of GroupC (required by the firewall rule). If no user belongs to all three groups, the rule cannot be satisfied.

Platform Support​

Forward models user-group and user-ID based firewall policies on the following platforms:

  • Palo Alto Networks (PAN-OS)
  • Check Point
  • Fortinet

These platforms must be collected with identity data (LDAP/user-IP mappings) for user-group resolution to function.

Where to Go Next​