Path verification

A scan tells you a port is closed.
PathMRI tells you who closed it.

Every scanner can report that port 5432 is unreachable. None of them can tell you which firewall dropped the packet, which rule did it, and what to change. PathMRI works out what the network says should happen, sends a real packet to find out what does, and reports the disagreement — which is the thing nobody else is looking for.

Download Read the manual

Predict, probe, reconcile

Two independent answers, then a comparison. Agreement is a verified path. Disagreement means something below policy is overriding it.

Step one

Predict

Read the firewall, security group or network policy that governs the path, and work out what it says should happen — naming the deciding rule.

Step two

Probe

Send a real packet from inside the source host or pod, and record what actually happened — reached, refused, or dropped, and where.

Step three

Reconcile

Compare the two. A policy that says allow while the wire says no is a finding, not an error — and it is the one that costs teams days.

Why a port scan is not enough

A port scanner observes one thing: whether an answer came back. Everything that matters after that is left to you and a lot of guessing.

A port scan

Tells you that it is blocked.

·Answers open, closed, or filtered — and nothing else.
·Runs from wherever the scanner sits, which is rarely where your app sits.
·Cannot see the firewall rule, the route, or the NAT that decided the outcome.
·Cannot tell a dropped packet from a host that is simply not listening.
·Says nothing about what to change to fix it.

PathMRI

Tells you where, why, and what to change.

→Names the device and the rule that dropped the packet, along the whole path.
→Probes from inside the source host — the real path, including its own firewall and routes.
→Reads the firewall's own configuration and predicts the verdict before testing it.
→Reconciles intent against reality — and flags it when policy says allow but the wire says no.
→Models the NAT, so you see the address the far end actually saw.
→Carries a fix — an inline remediation tip from an offline knowledge base.

A verdict with a reason attached

"Blocked" is not one thing. These are distinctions that change who fixes it, and they are made for you rather than left in a packet capture.

Result	What it actually means
open	A real service answered
open verified	End to end confirmed — the destination's listener received the probe. The path is clear even with no service running
closed	The packet arrived and was actively refused. Nothing is blocking it, so this is deliberately not reported as a block
filtered	Silence. Something is dropping packets, and the path strip shows where
app reset	The port is open and the application layer was reset — the signature of a UTM or app-layer block on an otherwise allowed flow
app silent	The handshake completed and zero bytes came back. Typically a stateful firewall that never saw the SYN-ACK
error	The probe never ran. This is never reported as closed

And the side it died on. Every blocked flow is attributed: the source host's own egress firewall, the destination's ingress, a registered firewall on the path, an intermediate device, or asymmetric routing — where nothing is denying it at all. The ticket goes to the right team the first time.

Firewall & cloud policy Where the prediction comes from: twelve policy sources, and the deciding rule by name. Three modes, six transports Where the probe comes from, and what each way of reaching a host can see. The fix, and the report What to do about the finding, from an offline knowledge base.

A scan tells you a port is closed.PathMRI tells you who closed it.