Route-Aware Topology

Current scope (corrected 2026-10-04)

Today route awareness is egress-level: for each subnet Infracast reads its route table and records whether it has any route to an internet gateway, NAT, VPN gateway, transit gateway or peering. The attack-path engine uses that to drop hops to public-IP assets from subnets with no way out. It does not yet check that a route exists to the specific destination: route destination CIDRs, BGP best paths, return paths and NAT translation are collected (NAT only partially) but not yet used for path validation. Paths that real routing would block can therefore still appear (over-reporting, not under-reporting). Destination-aware, route-based reachability, including static and dynamic routes and NAT, is planned as a dedicated build.

Infracast's route-aware topology engine validates actual network routing when computing reachability and attack paths — eliminating false positives from tools that assume routing works.

Why It Matters

Before route-aware topology, path analysis checked security groups and NACLs but assumed routing worked. A subnet with no route to an internet gateway would appear "internet-exposed" if its security group allowed 0.0.0.0/0 — even though traffic could never actually leave.

Route-aware topology closes this gap:

• A subnet with no IGW route is not flagged as internet-exposed
• VPC peering and Transit Gateway connectivity is computed from actual route propagation
• On-premises devices connected only via L3 routing (no LLDP/CDP) appear correctly in the graph
• "Show me all subnets that can reach the internet" is answered from routing truth, not SG approximation

What Gets Discovered

Cloud Route Tables

• AWS VPC route tables → routes_to edges for each destination/target pair (IGW, NAT GW, TGW, VGW, VPC Peering, Service Endpoint)
• Azure route tables and User Defined Routes
• GCP VPC routes and Cloud Router advertisements

On-Premises Routing

• Network device RIB (Routing Information Base) parsed from Cisco IOS, Juniper JunOS, Palo Alto
• next_hop edges created where next-hop IP resolves to a known device interface
• Protocols supported: OSPF, BGP, static, connected

Subnet Reachability Matrix

The Network Connectivity tab shows a subnet × reachability matrix:

Subnet	Internet	NAT	TGW	VPN/DX
prod-public-1a	✅	—	—	—
prod-private-1a	—	✅	✅	—
prod-isolated-1a	—	—	—	—

BGP Path Modeling

For environments with dynamic routing, Infracast collects and models BGP:

• Full BGP table from network devices and cloud BGP sessions (AWS Direct Connect VIFs, Azure ExpressRoute, GCP Cloud Router)
• Standard best-path selection per RFC 4271
• Backup paths retained for visibility and failover analysis
• Finding rules fire on BGP misconfigurations, weak authentication, and path anomalies

ECMP Flow-Aware Path Queries

When multiple equal-cost paths exist to the same destination, you can provide a flow 5-tuple to get a deterministic path result:

{
  "src_ip": "10.0.1.5",
  "dst_ip": "10.0.10.20",
  "protocol": "tcp",
  "src_port": 52341,
  "dst_port": 443
}

Result includes which ECMP leg the flow takes and the full path. Without a 5-tuple, all ECMP paths are enumerated.

Encrypted Tunnel Support

Reachability is computed through encrypted tunnels — not stopped at the tunnel boundary:

Protocol	Support
IPsec	AWS Site-to-Site VPN, Azure VPN GW, GCP HA VPN, Cisco IOS/ASA, Palo Alto, Juniper SRX
WireGuard	Linux hosts with wg show or config file access
GRE	Cisco, Juniper; unencrypted GRE flagged as a finding when carrying sensitive traffic
VXLAN / Geneve	VTEP-to-VNI mapping; L2-adjacent domain modeling

This means the path tracer and attack path engine can follow a path from a public subnet through a Site-to-Site VPN to an on-premises host — and report findings on the full chain.

Finding Rules

8 routing finding rules fire automatically:

Rule	Severity	Description
route-missing-igw	HIGH	Subnet tagged as public but has no route to an IGW
route-blackhole	MEDIUM	Active route points to a deleted or missing gateway
route-no-table	MEDIUM	Subnet has no associated route table
route-tgw-misconfigured	HIGH	TGW attachment exists but route not propagated
route-open-to-internet-via-igw	HIGH	Private subnet has a route to an IGW
route-unencrypted-cross-boundary	HIGH	Traffic crossing trust boundary without encryption
bgp-no-auth	MEDIUM	BGP session configured without authentication
bgp-weak-policy	MEDIUM	BGP peer accepts routes without filter policy

Setup

Route-aware topology is enabled automatically when Infracast discovers route tables and routing devices. No additional configuration is needed. For on-premises BGP and routing device data, ensure your network device credentials are configured in Settings → Connectors → Agentless.