The post How to Trace an Access Path Across Multiple Firewalls appeared first on www.firemon.com.

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.

*** This is a Security Bloggers Network syndicated blog from www.firemon.com authored by FireMon. Read the original post at: https://www.firemon.com/blog/trace-network-traffic-multiple-firewalls/