Encrypted Overlay Tunnel Introspection

Infracast extends reachability computation through encrypted overlay tunnels — treating them as virtual links in the route graph rather than opaque endpoints.

Why tunnels matter for reachability

Without tunnel introspection, the reachability walk stops at the tunnel boundary:

Subnet A → Route Table → IPsec Tunnel → [opaque]

With introspection, we follow the encryption domain to compute reachability on the far side:

Subnet A → Route Table → IPsec Tunnel → Remote subnet 10.20.0.0/24 → Remote resources

This affects:

• Path-tracer: can now trace through VPN tunnels to on-prem destinations
• Attack paths: lateral movement through a compromised host can follow VPN tunnels
• Compliance: "show me all paths where traffic is encrypted in transit" is answerable

Supported protocols

IPsec

• Collection: SA proposals, traffic selectors (proxy IDs), peer addresses, SA state
• Reachability: each (local_subnet, remote_subnet) traffic selector pair becomes a reachable_via_tunnel edge
  • Overlapping address space (Build 164): when a selector covers address space claimed by more than one subnet (reused RFC1918 ranges across VPCs/accounts/sites) the selector alone cannot identify the far side, so no reachability edge is drawn; a tunnel_to_unknown edge with far_side_ambiguous=true and a reason records it instead. An ambiguous local side is narrowed to the subnets the tunnel's own device contains, if any. Resolving these properly requires route-based reachability (planned).
• Supported devices: Cisco IOS/ASA, Palo Alto, Juniper SRX, AWS Site-to-Site VPN, Azure VPN Gateway, GCP HA VPN

WireGuard

• Collection: AllowedIPs per peer (from wg show all or /etc/wireguard/*.conf)
• Reachability: AllowedIPs entries become routes_to edges via the WireGuard interface — they're literally routing entries

GRE

• Collection: tunnel interface source/destination, routes pointing at the tunnel interface
• Reachability: routes via GRE interface → routes_via_gre edges to the GRE destination
• Note: GRE provides no encryption — findings check for GRE tunnels carrying sensitive traffic without IPsec

VXLAN / Geneve

• Collection: VTEP-to-VNI mapping from device configuration
• Reachability: VTEPs sharing a VNI are modeled as L2-adjacent (same broadcast domain)
• Overlay domain: VXLAN subnets are tracked as a separate routing domain from the underlay

Graph representation

Tunnel reachability is represented as typed edges in the topology graph, enabling the path tracer and attack path engine to reason about connectivity through encrypted overlays.

Finding rules

Rule ID	Severity	Description
NETWORK-TUNNEL-001	HIGH	Tunnel using deprecated cipher (DES, 3DES, MD5 HMAC)
NETWORK-TUNNEL-002	HIGH	Tunnel encryption domain overlaps with non-encrypted route (split-tunnel exposure)
NETWORK-TUNNEL-003	HIGH	WireGuard AllowedIPs is 0.0.0.0/0 from a low-trust peer
NETWORK-TUNNEL-004	MEDIUM	IPsec SA up but no traffic (possible policy/selector mismatch)
NETWORK-TUNNEL-005	MEDIUM	Tunnel terminates on internet-facing interface without rate limiting (DoS amplification)

Limitations

• One-sided visibility: if only one tunnel endpoint is in inventory, we emit tunnel_to_unknown and stop reachability. No fake nodes are synthesized for the far side.
• Managed tunnels: cloud-managed hub products (Azure Virtual WAN, Cisco SD-WAN vManage) may not expose enough config for full introspection. These are marked "managed_tunnel_opaque": true.
• Application-layer tunnels: TLS, SSH, and application proxies are not modeled (different layer).
• Zero-trust mesh (Tailscale, Twingate, Netbird): proprietary control planes require dedicated integrations, not in scope here.