Skip to main content

Layer-7 URL Filtering

A URL filter pins a path query to a specific web resource, so path search applies the URL-based firewall and SD-WAN routing policies the traffic would hit.

url vs domain​

Path search offers two Layer-7 filters for web traffic. Both match the same domain and TLD, but they differ in scope:

Aspecturldomain
Matches onDomain, TLD, and URL pathDomain and TLD only (URL path left unconstrained)
TransportRequires TCP or UDP, since URLs ride HTTP/HTTPSAny IP protocol
Use forURL-filtering policies that match a path or run over HTTP/HTTPS (Palo Alto, Cisco FTD, Fortinet, Forcepoint)Domain-based access policies that match a bare domain regardless of transport (Zscaler ZPA)

A query can carry url or domain, not both.

The domain filter leaves the URL path unconstrained, so it also matches the domain condition of a URL-filtering rule. The domain filter can be used to test whether a policy admits a domain at all; the url filter can be used to test a specific path or a rule that depends on HTTP/HTTPS transport.

URL Structure​

Forward decomposes URLs into three segments for matching:

SegmentExample from xyz.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1Limits
Domainxyz.jira.local.forwardnetworksMax 4 segments
TLDco.usMax 2 segments
Pathprojects/fwd/plans/plan-1Max 4 segments

The domain filter uses the Domain and TLD rows only; it does not match the URL path (projects/fwd/plans/plan-1).

Not supported in the URL query clause: scheme (https://), port (:8338), and query parameters (?key=value). These are stripped before matching. IP addresses in the URL host position are accepted but only the path portion is matched — the domain and TLD fields are set to empty and will not match any policy rule that specifies a domain or TLD condition.

Query Syntax​

Add a url filter after from() alongside other packet header filters:

from(10.1.0.5) ipv4_dst(10.2.0.10) url(xyz.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1) z(delivered)

This asks: "Show me delivered paths for traffic from 10.1.0.5 to 10.2.0.10 accessing this URL."

To match a domain regardless of transport protocol or path, use domain instead:

from(10.1.0.5) ipv4_dst(10.2.0.10) domain(xyz.jira.local.forwardnetworks.co.us) z(delivered)

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

Queries without a URL​

When no url filter is specified and traffic passes through a firewall rule containing a URL match, the system skips that URL clause during evaluation. The assumption is that if you are not investigating a specific URL, you are not interested in URL-specific policy matches. This prevents URL-dependent deny or permit rules from affecting results when URL context is absent from the query.

Wildcard Matching​

Forward supports wildcard patterns in URL-based firewall policies. When your query contains a full URL but the matching policy uses wildcards, the system resolves the match and shows the applicable filter values in the panel.

Supported wildcard positions​

  • Prefix-wildcarding in subdomains: *.jira.local.forwardnetworks.co.us/projects/fwd
  • Suffix-wildcarding in TLD: xyz.jira.local.forwardnetworks.co.*
  • Suffix-wildcarding in path: *.jira.local.forwardnetworks.co.us/projects/*
  • Combined wildcards: *.jira.local.forwardnetworks.*

Only one wildcard per segment is supported, and it must appear at the boundary (beginning or end of the segment).

How wildcard resolution appears in results​

When a query URL matches a wildcarded policy, the filter panel resolves wildcards using known values from the snapshot:

  • If the subdomain in your query (e.g., xyz) is recognized elsewhere in the snapshot's URL policies, the panel shows the fully resolved URL: xyz.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1
  • If the subdomain is not recognized, the panel preserves the wildcard: *.jira.local.forwardnetworks.co.us/projects/fwd/plans/plan-1

The same logic applies to TLD and path segments. Unrecognized segments remain wildcarded; recognized segments are resolved to their concrete values.

Implicit wildcards​

A policy that specifies a partial URL implicitly wildcards the remaining segments. For example, a policy matching *.jira.local.forwardnetworks.co.us/projects implicitly wildcards everything after /projects in the path. The system treats this the same as explicit suffix-wildcarding.

URL Category Filtering​

URL category filters constrain traffic based on the category classification assigned to URLs by policy devices:

from(10.1.0.5) url_category(social-networking) ipv4_dst(10.2.0.10)

Categories are defined per-vendor and may include both predefined categories (e.g., social-networking, malware) and custom categories configured on the device. Available categories appear as suggestions in the query bar.

Platform Support​

URL-based policies​

Forward models URL-based firewall and routing policies on a broad set of platforms:

CategoryPlatforms
Next-gen firewallsPalo Alto (PAN-OS), Fortinet, Cisco FTD, Forcepoint
SD-WANSilverPeak EdgeConnect, Viptela vSmart, CloudGenix, VeloCloud, Versa (Switch and SASE)
CloudAzure Firewall, Azure App Gateway, Azure Front Door, AWS NLB, AWS Network Firewall, Zscaler ZPA
Load balancersF5, AVI Vantage, IBM Load Balancer
Wireless / accessMeraki MX, Meraki MR, Mist AP, 128 Technology

URL category policies​

URL category matching is supported on platforms that define category-based rules, including Palo Alto and Meraki.

SD-WAN Routing and URLs​

On SD-WAN platforms that route traffic based on URL (such as SilverPeak Business Intent Overlay), URL filters let you determine which tunnel or path is selected for traffic carrying a specific URL. Query with the URL of interest and inspect the forwarding decisions in the path results to see which overlay tunnel was chosen.

Where to Go Next​