Network reachability

Reachability answers a single, concrete question: *can traffic get from here to there — and if not, which layer is blocking it?* The platform traces the packet through every network control on the path and shows each one.

Start from the map — click the component you care about

The primary way to run a test is the network topology map (/network): click a VPC, subnet, instance, load balancer, database or gateway, then press Test reachability in the right-hand inspector. That component becomes the fixed anchor of the test — shown as a chip (name · type · VPC · account), not an editable address — and you only choose three things:

1. Direction, as an arrow: [this component] ──▶ [other] (outbound — this component is the source) or [this component] ◀── [other] (inbound — this component is the destination). Flipping the arrow re-runs the same pair the other way, which is often a different answer: a security group can allow one direction and block the other.
2. The other endpoint — either *pick a component* (a searchable list showing name · type · VPC · account, so two identically-named default VPCs are distinguishable) or *type an IP* (any IPv4, including a public address such as 8.8.8.8).
3. Protocol and port (tcp/443 by default).

The verdict, the layered hop list and the live probe all appear inside that modal. Press Esc (or click outside) to close it; focus returns to the button you opened it from.

The standalone analyzer — when you only have two addresses

The Reachability analyzer panel below the map is still there for the case where neither endpoint is a component you can point at: type a source IP and a destination IP (optionally prefilling one from the component picker), choose protocol and port, and analyze. It renders exactly the same verdict, hops and probe evidence as the map flow.

What it checks — every layer, in order

A packet from an instance to another endpoint passes through a fixed sequence of controls. The analyzer evaluates each one and shows an allow / deny / not-applicable verdict with the matched rule and a plain-English reason:

1. Source security group — egress. Does the source instance's security group allow the traffic out to the destination?
2. Source subnet network ACL — egress. Does the source subnet's NACL (evaluated in rule-number order) permit it out?
3. Route table. Which route in the source subnet's route table matches the destination — and what does it point at (local, an internet gateway, a NAT gateway, a peering/transit-gateway connection, or a VPC endpoint)?
4. Gateway. The gateway hop itself: *local* is same-VPC delivery; an internet gateway needs the source to have a public IP; a NAT gateway is egress-only (outbound works, inbound cannot be initiated); peering / transit gateway carries cross-VPC traffic; a VPC endpoint reaches an AWS service privately.
5. Destination subnet network ACL — ingress. Does the destination subnet's NACL allow the traffic in?
6. Destination security group — ingress. Does the destination instance's security group allow it in? (This is the most common blocker.)
7. Return path. Because network ACLs are stateless, the reply is checked too — the destination NACL egress and the source NACL ingress must permit the return. Security groups are stateful, so their reply is automatically allowed.

Reachable or not — and why

The result is a big REACHABLE or NOT REACHABLE header, a one-line summary, and the full layered diagram top-to-bottom. If the path is blocked, the offending layer is highlighted ("blocked at destination security group — no ingress rule for tcp/443 from 10.0.1.41"), so you go straight to the fix instead of guessing.

Overlapping CIDRs — when an IP alone is ambiguous

Two networks can legitimately carry the same address range: every AWS default VPC — in every region and every account — is 172.31.0.0/16, so 172.31.8.41 may exist in several of them at once. When the matches for an IP span more than one network, the analyzer refuses to guess (an authoritative-looking verdict about the wrong network would be worse than an error). Instead it lists the candidate networks — VPC/VNet name, CIDR, owning cloud account, provider, region, and the specific matched instance or subnet — and you pick the one you meant.

• Disambiguation is reactive, not a standing control: there is no scope dropdown to fill in up front. The candidate cards appear only when an analysis actually comes back ambiguous, and clicking a candidate pins that endpoint's network and re-runs in one step — in the map modal and in the standalone panel alike.
• An endpoint chosen as a component — the map anchor, or either picker — can never be ambiguous: a resource id resolves directly, so no scope is ever requested for it.
• An IP owned by exactly one instance stays unambiguous even when the surrounding CIDRs overlap — an exact resource match beats CIDR containment.
• The verdict header shows each endpoint's resolved network and account (10.20.0.4 · vpc-0b63… (acct)), so a screenshot of a result is self-describing.

Where the data comes from

Security groups and network ACLs are discovered from your connected AWS account (DescribeSecurityGroups, DescribeNetworkAcls) alongside each instance's public IP and security-group membership (DescribeInstances). Like IAM discovery, these calls are best-effort: if the platform's role is missing a describe permission, that data degrades to empty and the account stays healthy — the analyzer simply has less to reason about, and says so.

Prove it with a live probe

The analyzer reasons about what the configuration permits. Verify with a live probe goes one step further: it sends *real traffic* from the source instance and returns the cloud provider's own execution record as evidence. Cushy composes one small test script server-side (a bash /dev/tcp TCP connect or ping for ICMP on Linux; Test-NetConnection / Test-Connection on a discovered Windows server) and executes it on the source instance through that cloud's native command channel — SSM Run Command on AWS, Run Command on Azure, Cloud Assistant on Alibaba Cloud — using the same keyless federation your cloud connection already uses: no extra agent beyond what those platforms already run, and no credential ever leaves the platform.

• The evidence is customer-verifiable. The result panel shows the provider's execution id, the executed document, exit code, raw output, timestamps and the measured latency — and names exactly where to find the same execution in *your own* console: AWS → Systems Manager → Run Command → command history (the SSM command id); Azure → the VM → Operations → Run command history (the async operation id); Alibaba Cloud → ECS → ECS Cloud Assistant → command execution result (the InvokeId). The proof does not depend on trusting Cushy.
• Agreement = proven. When the probe result matches the analyzer's verdict, the verdict is proven with evidence — *at that moment, from that instance*. It is a point-in-time proof, not a guarantee for all time.
• A contradiction is a finding, not an error. If the configuration permits the path but the live probe cannot connect, something the config model can't see is broken — a dead NAT gateway, a blackholed route, the remote service being down, or a host firewall inside the OS. Cushy flags this prominently (and audits network.probe_contradiction) instead of hiding it. The reverse contradiction (analyzer says blocked, probe connects) means the synced model is missing a rule or path — re-sync and review.
• A failed connection is a result. Connection refused / timed out comes back as *not connected* with the raw output as evidence — never as an exception.

Per-cloud availability and prerequisites

The probe is gated like other command execution (Deployer and above — it runs a command on your instance), audited (network.probe_executed with the execution id), and the command is composed server-side from a validated IP and port only — the SAME script travels to all three clouds, so what you see in your provider's execution history is exactly what ran. TCP and ICMP only (there is no reliable UDP test); the static analyzer still covers UDP configuration.

Limitations

• Analysis is over your synced topology — connect a cloud account first; a never-connected org gets an honest "no topology yet".
• IPv4 only; the protocol/port model covers tcp/udp/icmp/all.
• Cross-VPC reachability follows a peering / VPN / transit-gateway connection when one exists; explicit cross-VPC route-table entries and Azure/Alibaba security models are on the roadmap.
• The static analyzer reasons about configuration (SGs, NACLs, routes, gateways); the live probe is the packet-level check — AWS, Azure and Alibaba Cloud today (SSM Run Command / Run Command / Cloud Assistant), tcp/icmp only, instance-sourced only. GCP has no run-command API (researched — SSH over IAP is the manual path).
• A passing probe proves connectivity at that moment from that instance — evidence, not a permanent guarantee; re-probe after changes.