EN 
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.