Reachability analysis across firewalls and the host

What the engine answers

Given a source, a destination and a port, the reachability engine finds the firewalls between them, evaluates each one the way FortiOS would, and consults the destination machine's own firewall policy where an endpoint console holds it. The verdict is permitted by policy, denied, or indeterminate with the reason, and it is always accompanied by the deciding rule on each hop, every rule that would have matched below it, and the evidence for each step. Every other part of MagenX asks this engine: attack simulation asks it for each edge of a route, crown jewels asks it for each subnet that might reach the asset, and the host page asks it for the host's inbound exposure.

The engine is written to refuse an answer it cannot prove rather than to produce one that reads well. Most of what follows describes where it stops.

The path is walked, from both ends

A path is not a walk from one end. Both ends walk toward each other, the set of devices on the path is the same whichever end you start from, and the boundary between what the scan collected and what it did not is drawn on the diagram. The source firewall is the device holding the most specific local entry for the source address: an interface network that contains it, a route with no gateway, or an address object an author tied to an interface. From there the most specific route for the destination gives a gateway, the firewall whose interface holds that gateway is the next hop, and the walk ends on the device where the destination is local. Only one device may qualify as a next hop; several firewalls on one transit segment means the path cannot be read, and the engine says so instead of picking one.

A zone is identified by the pair of device and zone name, never by the name alone, because the same name on two devices is two zones. Where a hop's zone membership is not collected, the search widens to every zone the hop could be in; it is never narrowed by a guess and never voided.

Where it refuses to answer

A guessed origin voids the verdict. If the source cannot be placed on a device from collected facts, no hop is adjudicated, unless the destination side anchors the path on its own
Two endpoints on the same device resolving out of the same interface toward the same next hop are below the collection boundary: the traffic never crosses a firewall the scan read, and the verdict is indeterminate with that reason
A packet whose source and destination resolve to the same interface on a device is a hairpin, and a rule evaluated across that pair is refused at the point where the record is sealed
A firewall the scan never read is not a control that is holding. Its absence is stated; it lends no protection to the score
An address object that resolves on the device, FQDN, geography, a fabric connector, an Internet Service, is declared unevaluatable rather than matched
A rule with a schedule other than always, a policy route, SD-WAN, source NAT and an inspection profile that could drop an accepted session are each stated as a limit on the verdict

The machine is the last hop

A path the firewalls permit and the destination's own firewall drops is not a permitted path. The engine reads the host's firewall policy from the endpoint console that manages it, from the same discovery sweep the asset discovery page shows, and evaluates the same packet against it: inbound on the destination, from the source address to the asked port, and outbound on the source. First match wins over rules that are in effect and not shadowed. Local means this machine and remote means the other end, which is host-relative and not source and destination; the fallback is the policy's own default, never the operating system's. A rule whose match cannot be settled, narrowed to a program or a service, pinned to the ephemeral end's port, or naming an address the scan could not read, withholds an allow and is stepped over as a deny.

The host's verdict has five words: blocks, permits, not established, not governed, not consulted, with the reason on the record when nothing could be consulted. The network verdict never changes because of it. "Permitted by the network and dropped at the host" is a fact worth its own field, and every field of every rule the walk considered is shown beside the packet.

What the answer looks like

Three rows, one per layer: the source's own firewall, the network path device by device, and the destination's firewall. Each station is coloured by what happened to the packet there, green where it passed, red where it stopped, grey where nothing could be read, and the source is always the first column. Beneath the rows is the deciding rule for each hop and the rules that would have matched below it, each labelled with how specifically it matched, so a permit from a broad any-to-any rule is visible as one. The verdict wording is permitted by policy, never reachable, because policy is what was read.

What it does not do

It does not send a packet. Every verdict is computed from collected configuration and routing, and the wording says so. It does not read Windows Defender Firewall on a host that has no endpoint console policy, and it says not consulted rather than permits on such a host. It does not model asymmetric return paths or session helpers, and it does not evaluate firewalls from vendors other than Fortinet.

FAQ

How is this different from a firewall rule search?

A rule search finds rules that mention an address. The engine finds the rule that would decide a specific packet on the specific interface pair the traffic uses, in sequence order, on every device on the path, and then asks the destination's own firewall the same question. A rule that mentions the address and never runs is shown as exactly that.

Why does it sometimes say indeterminate?

Because the honest answer is that the scan did not collect enough to prove the path: the source could not be placed on a device, two firewalls both qualified as the next hop, or the traffic never crosses a device that was read. Each case names its reason. An indeterminate verdict with the reason is worth more than a confident one with none.

Which sweep does the host firewall come from?

The newest completed discovery sweep that has rows, which is the same one the asset discovery page shows, and the answer names it. A host that has no console-managed policy is reported as not consulted.

Does it cover Windows Defender Firewall?

Only where an endpoint console manages a host firewall policy and exposes it, which is the policy the engine reads. A host's local Windows firewall on its own is not read, and the verdict says not consulted rather than guessing.

Can I ask it about any two addresses?

Yes. Reachability has its own page in the product, with a source, a destination and a port, and every host cell on the platform opens the host's page, where the inbound exposure has already been asked.

Reachability analysis, from the source to the last hop