Support for Palo Alto Networks Strata Cloud Manager is available now. Learn more →

Published:

How to Trace an Access Path Across Multiple Firewalls

by FireMon

When a connection fails or succeeds unexpectedly, the first question is simple: Why? But answering that question is not simple in modern environments. A single connection between two systems may traverse:

  • Multiple firewalls
  • Different rule sets and priorities
  • Network zones and routing paths

Reviewing one device at a time does not provide a complete answer. This post explains how to trace an access path across multiple firewalls so you can determine exactly why traffic is allowed or blocked.

The Core Problem: Access Is Determined Across the Environment

Native firewall management tools are typically scoped to a single device. They show:

  • Rules
  • Logs
  • Configuration state

They do not show how traffic is evaluated across multiple enforcement points. A connection is only successful if it is allowed at every step along the path.

What Is an Access Path?

An access path is the sequence of evaluations that determine whether traffic can move from a source to a destination. It includes:

  • Source and destination systems
  • Ports and protocols
  • Every firewall, control point, and layer 3 device along the route
  • The rules that allow or deny traffic at each step

Tracing an access path means identifying each of these elements and how they interact.

Inputs and Outputs

Inputs

  • Source system
  • Destination system
  • Port and protocol
  • Firewall configurations across the environment
  • Network topology and routing paths
  • Object groups and address mappings

Outputs

  • Whether the connection is allowed or blocked
  • The sequence of enforcement points involved
  • The rules that permit or deny traffic
  • Alternate paths that may allow connectivity

Step 1: Define the Connection

Start with a specific question: Can App_Server communicate with DB_Server on port 1433? Without a clearly defined connection, tracing becomes ambiguous.

Step 2: Identify the Expected Path

Determine how traffic should flow through the network. This includes:

  • Source zone or network
  • Intermediate segments
  • Destination zone or network

In many environments, there are multiple possible paths. Understanding topology is required before evaluating rules.

Step 3: Evaluate Each Enforcement Point

At each firewall or control point: 1. Identify relevant rules 2. Evaluate rule order and precedence 3. Determine whether traffic is allowed or denied

Example

Firewall A: Allow App → DB (1433) Firewall B: Deny App → DB (1433) The connection is blocked because all enforcement points must allow the traffic.

Step 4: Expand Object Groups

Rules often reference object groups rather than individual systems. These groups may include multiple addresses.

Example

Allow App → DB_Group (1433) DB_Group may resolve to: DB_Server Backup_DB Reporting_DB Tracing requires evaluating all expanded members.

Step 5: Evaluate Rule Interactions

Rules do not operate independently. Key factors include:

  • Rule order
  • Overlapping conditions
  • Broad rules that override specific ones

Example

Rule 1: Allow App → Any (Any Port) Rule 2: Deny App → DB (1433) The deny rule exists but is never reached.

Step 6: Account for Alternate Paths

Even if one path blocks traffic, another path may allow it.

Example

Path 1: Firewall A denies App → DB Path 2: Firewall B allows App → DB If routing allows Path 2, the connection succeeds. Tracing must include all possible paths.

Step 7: Determine Final Outcome

After evaluating:

  • All enforcement points
  • Rule interactions
  • Object expansions
  • Possible paths

You can determine:

  • Whether the connection is allowed or blocked
  • Which rule is responsible
  • Where control should be adjusted

Example: Why a Connection Is Allowed

Question Can App_Server reach DB_Server on port 1433? Configuration Findings Firewall A: Allow App → DB_Group (1433) Firewall B: No explicit deny Rule order: Broad allow takes precedence Effective Outcome App → DB (1433) App → Backup_DB (1433) The connection is allowed due to object group expansion and rule precedence.

Why Manual Tracing Breaks Down

Manual tracing becomes difficult when:

  • Multiple devices are involved
  • Rule sets are large and complex
  • Object groups expand significantly

This leads to:

  • Incomplete analysis
  • Incorrect assumptions
  • Slow troubleshooting

Evaluating Access Paths Using a Policy Model

A policy model provides a structured way to evaluate access. It combines:

  • Firewall configurations
  • Network topology
  • Object resolution
  • Rule evaluation logic

This allows teams to:

  • Evaluate connectivity across the environment
  • Identify all applicable rules
  • Understand why access is allowed or blocked

The Role of FireMon

FireMon enables access path evaluation by:

  • Building a normalized policy model across firewalls
  • Incorporating topology and routing
  • Evaluating connectivity between systems
  • Identifying the rules that control access

This provides a consistent way to answer: Why is this connection allowed or blocked?

Key Takeaways

  • Access is determined across multiple enforcement points
  • A connection must be allowed at every step
  • Rule order and object expansion affect outcomes
  • Alternate paths can enable unexpected connectivity
  • Evaluating access requires both policy and topology

Wrapping it Up

When troubleshooting access, the goal is not to find a rule. The goal is to leverage both control point and network topology to provide an end-to-end view of the connection, allowing for a clear explanation as to why traffic is or is not allowed.

[ FireMon ]

The Role of FireMon

FireMon enables access path evaluation by building a normalized policy model across firewalls, incorporating topology and routing, evaluating connectivity between systems, and identifying the rules that control access.

Request a Demo

Frequen­tly Asked Questions

Tracing network traffic across multiple firewalls means evaluating how a connection is handled at every enforcement point between a source and destination. It includes analyzing rules, routing paths, and object groups to determine whether traffic is ultimately allowed or blocked across the full environment.

Tracing traffic is difficult because each firewall evaluates rules independently, while actual connectivity depends on all enforcement points combined. Rule order, object group expansion, and multiple routing paths make it hard to understand outcomes by reviewing individual devices in isolation.

Start by defining the source, destination, port, and protocol. Then identify the expected network path, evaluate rules at each firewall, expand object groups, and account for rule interactions and alternate routes. The final outcome depends on how all enforcement points evaluate the connection together.

Traffic outcomes depend on rule order, allow and deny conditions, object group membership, and network routing paths. A connection must be permitted at every enforcement point, and even small changes in policy or topology can alter whether traffic is successfully allowed or blocked.

A deny rule may not take effect if it is overridden by a broader allow rule with higher precedence or if it is never reached due to rule order. In some cases, alternate network paths may bypass the deny rule entirely, resulting in unexpected allowed traffic.

Accurate analysis requires evaluating traffic across the full environment, not just one device. A policy model that incorporates firewall rules, topology, and object resolution can identify all enforcement points and rule interactions, providing a clear explanation of why traffic is allowed or blocked.