Path Tracer

Path Tracer analyzes network reachability through your infrastructure, evaluating security groups, NACLs, and routing to determine if traffic can flow between resources.

Overview

Unlike simple port scanners, Path Tracer uses your infrastructure graph to simulate traffic flow through all network controls:

• Security Groups — Instance-level firewalls
• Network ACLs — Subnet-level firewalls
• Route Tables — Routing decisions
• VPC Peering — Cross-VPC connectivity
• Transit Gateways — Hub-and-spoke routing
• Internet/NAT Gateways — Internet egress/ingress

Use Cases

Security Validation

• "Can the internet reach my database?"
• "Is SSH blocked from public subnets?"
• "Can prod talk to dev?"

Troubleshooting

• "Why can't my app reach the API?"
• "What's blocking traffic to the cache?"

Compliance

• "Prove that PCI assets are isolated"
• "Document network segmentation for auditors"

How It Works

1. Start at source — Identify the source node
2. Evaluate each hop — Check SGs, NACLs, routes
3. Follow the path — Traverse through network infrastructure
4. Report decision — ALLOW, DENY, or UNKNOWN at each hop

Using Path Tracer

1. Navigate to Path Tracer in the sidebar
2. Select a Source Node from the dropdown
3. Enter Destination (IP address or CIDR)
4. Choose Protocol (TCP, UDP, or ICMP)
5. Enter Port number
6. Click Trace Path
7. View the hop-by-hop analysis

Understanding Results

Decision	Meaning
✅ ALLOW	Traffic permitted through this hop
❌ DENY	Traffic blocked at this hop
⚠️ UNKNOWN	Cannot determine (missing data or complex rules)

API Usage

Trace a Path

POST /api/v1/tenants/{tenantID}/pathtracer/trace
Content-Type: application/json

{
  "source_node_id": "aws:us-east-1:ec2:i-0abc123",
  "destination_cidr": "10.0.2.100/32",
  "protocol": "tcp",
  "port": 5432
}

Response:

{
  "reachable": false,
  "hops": [
    {
      "node_id": "aws:us-east-1:ec2:i-0abc123",
      "node_name": "web-server",
      "decision": "UNKNOWN",
      "reason": "Source node"
    },
    {
      "node_id": "aws:us-east-1:sg:sg-web",
      "node_name": "web-security-group",
      "decision": "ALLOW",
      "matched_rule": "egress:tcp:0-65535:0.0.0.0/0",
      "reason": "Egress SG allows all outbound"
    },
    {
      "node_id": "aws:us-east-1:nacl:acl-123",
      "node_name": "private-nacl",
      "decision": "DENY",
      "matched_rule": "inbound:deny:5432:10.0.1.0/24",
      "reason": "NACL denies PostgreSQL from web subnet"
    }
  ],
  "summary": "Traffic BLOCKED at private-nacl"
}

Common Patterns

Internet to Instance

Internet Gateway → Route Table → NACL → Security Group → Instance

Instance to RDS

Instance → Security Group (egress) → Route Table → NACL → RDS Security Group (ingress) → RDS

Cross-VPC via Peering

Instance → SG → Route Table → VPC Peering → Route Table → NACL → SG → Instance

Cross-VPC via Transit Gateway

Instance → SG → Route Table → Transit Gateway → Route Table → NACL → SG → Instance

Limitations

• Stateful vs Stateless — Security Groups are stateful (return traffic automatically allowed), NACLs are stateless
• Complex Rules — Some rule combinations may show UNKNOWN
• Missing Data — Requires complete infrastructure discovery
• Application-Layer — Does not analyze WAF, ALB rules, or application-level firewalls

Best Practices

1. Test Both Directions — Trace A→B and B→A for the full picture
2. Use Specific CIDRs — /32 for single hosts gives clearest results
3. Check After Changes — Re-trace paths after SG/NACL modifications
4. Document for Compliance — Export traces as evidence for auditors
5. Regular Validation — Schedule periodic traces for critical paths

Route Validation (Build 90)

Starting with Build 90, the path tracer validates the routing layer before checking security groups. This means that a path can now be blocked at three distinct layers:

Result	Icon	Meaning
REACHABLE	🔓	All checks pass — traffic can flow
ROUTE BLOCKED	🛣️	Route table has no path — traffic dropped before reaching SG
BLOCKED	🔒	Route exists, but SG/firewall rule denies the traffic

How Route Validation Works

1. The tracer looks up the source subnet's associated route table via associated_with edges.
2. If the destination is internet-bound (0.0.0.0/0 or a public IP), it checks internet_egress and nat_egress flags.
3. If no internet route exists, the result is route_blocked = true and the trace stops early — no SG check needed.
4. Backward compatible: If no route data has been collected for the tenant (route table discovery not run), the tracer skips route validation and proceeds as before.

Route Hops in Results

Each hop in the path result now includes a route_decision field describing what the route table decided:

{
  "NodeID": "aws:us-east-1:ec2.route_table:rtb-0abc",
  "NodeType": "aws.ec2.route_table",
  "Decision": "ALLOW",
  "RouteDecision": "routes_to IGW via route table aws:us-east-1:ec2.route_table:rtb-0abc"
}

Prerequisites

Route validation requires that route table discovery has been run. Enable this by using a cloud credentials connector (AWS, Azure, GCP) — route tables are discovered automatically.