What PathMRI is
PathMRI answers one question well:
Can this reach that, on this port — and if not, exactly where does the packet die?
It answers with a real packet rather than a model, and it can do so without installing anything on the machines it tests. Around that answer it builds the things you need once the answer is no: which firewall's policy denies the flow, what NAT rewrote the addresses on the way, whether the return path comes back a different way, whether the name even resolves to the address you tested, and whether any of it changed since yesterday.
How it answers#
Every check is three steps, and the third is the one that matters.
- Predict. PathMRI reads the policy that governs the flow — the firewall's own configuration, a cloud security group, a Kubernetes network policy — and works out what it says should happen, naming the rule that decides.
- Probe. It sends a real packet from inside the source host, and records what actually happened: reached, refused, or dropped, and where.
- Reconcile. It compares the two. Agreement is a verified path. Disagreement is a finding — policy says allow and the wire says no, which is the case that costs teams days.
A port scanner only ever does step 2, from wherever the scanner happens to sit.
The pieces#
| Piece | What it is |
|---|---|
| Controller | The application you install. It serves the console in your browser, holds the database, and reaches out to hosts and devices. One process, no external services. |
| Agent | An optional small binary on a target host. It can run as a service, or be pushed for a single check and deleted afterwards. |
| Network devices | Read-only connections to your firewalls, routers and cloud control planes. PathMRI reads their policy; it does not need to change it. |
The words the console uses#
Host and network device. A host is something you verify from or to — a machine, a container, a pod. A network device is something on the path: a firewall, router or switch, whose policy PathMRI reads and which it can name as the place a packet stopped. A device can be the far end of an ad-hoc check, traced to its management address, but it never originates a probe.
Management address and scan address. The management address is how the controller reaches a host to run a check. The scan address is the address other machines use to reach that host's services — so it is the address firewall policy is evaluated against, and the one probes are aimed at. They differ whenever a host sits behind a load balancer or a NAT. Leave the scan address blank and the management address is used for both.
Connection mode and connection type. The mode is what runs on the host; the type is how the controller talks to it. They are separate choices:
| Mode | What runs on the host |
|---|---|
| Agent | A small service that starts with the machine. Fastest, and can measure everything. Removable at any time. |
| Agentless | Nothing. Checks run over SSH or WinRM using tools the host already has. |
| Ephemeral | A throwaway agent is pushed over SSH, runs in memory, and is deleted when the check ends. Agent-grade depth, nothing left on disk. |
| Type | How the controller connects |
|---|---|
ssh |
OpenSSH — the agentless path, and the tunnel a managed agent is reached through |
agent |
Straight to the agent's own port |
winrm |
WS-Management, for Windows fleets that have WinRM but not OpenSSH |
docker |
The host is a Docker engine |
kube |
The address is a kubeconfig context on the controller — no node SSH needed |
Declared and observed. A declared answer comes from configuration: what a policy says should happen. An observed answer comes from a live state table on the device: what it is doing right now. PathMRI keeps the two apart everywhere, and never invents the observed half — where a platform does not expose one, it says so rather than implying a measurement.
Connectivity rule. A rule is an expectation you write down: these sources should reach these destinations on these ports. Rules are what a verification run executes, what a scheduled re-check re-runs, and what drift is measured against.
What a result means#
"Blocked" is not one thing, and the difference decides who fixes it.
| Result | What it means |
|---|---|
| open | A real service answered. |
| open verified | End to end confirmed — the destination's own 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 view shows where. |
| app reset | The port is open and the application layer was reset — the signature of a UTM or application-layer block on an otherwise allowed flow. |
| app silent | The handshake completed and nothing came back at all. Typically a stateful firewall that never saw the reply. |
| error | The probe could not run. This is never reported as closed. |
Every blocked flow is also attributed to a side: the source host's own firewall, the destination's, a firewall on the path, an intermediate device, or asymmetric routing — where nothing is denying it at all and the return leg simply goes another way.
What it will not do#
- It will not guess a vendor. Tell PathMRI a device is something it does not recognise and it answers unknown, quoting the string it did not understand — rather than reading a device with the wrong parser and being confidently wrong.
- It will not present an unmeasured path as closed. A check that could not run is reported as unmeasured. This distinction is the difference between evidence and an assumption.
- It will not claim more than the transport can see. Each way of reaching a host measures a different amount, and a result says what was and was not established.
Where to go next#
- Install and first run — from a package to a first verified path.
- Reaching a host — the three modes, and the credentials each one needs.
- Firewalls and cloud policy — what PathMRI reads on each platform.