PathMRI

Overview/Features/VPN & tunnels

VPN & tunnels

Up is the weakest claim
a VPN can make.

A tunnel can report connected while nothing crosses it. PathMRI asks the two questions that actually matter: is this flow really going through the tunnel, and is the tunnel really carrying it?

Four signals, ranked by what they prove

PathMRI never says "tunnel" because an interface is named like one. Each signal carries its own strength, and the strongest claim needs two of them to agree.

SignalHow it firesStrength
Interface nameThe winning route leaves on an interface named like a tunnelHeuristic — and it says so
VPN gateway next hopThe next hop resolves to a device you registered as a VPN gateway. The device's name deliberately does not countCorroborated
Firewall selectorA parsed tunnel's protected selectors cover this flow's exact tupleDeclared
Tunnel interface routeThe winning route's egress interface is the interface the matched tunnel binds — catching names no family could recogniseRoute signal
A route signal plus a config match is confirmed. Config alone is declared, a gateway match alone is corroborated, and a name alone is heuristic. Encryption stays a separate question: GRE, IPIP and SIT are tunnels that carry plaintext, so the crypto verdict has its own field — and PathMRI never claims a packet was encrypted.

Health, not a green light

A live lab produced a tunnel whose keepalives kept flowing while the counters sat frozen and every packet left in cleartext. "Up" was true and worthless.

Never collapsed

Phase 1 and phase 2, apart

The classic partial failure is P1 up and P2 down: the device says connected and nothing can cross. Two fields, never one boolean — and "not read" never reads as "down".

Movement

Counters sampled twice

A big number on a counter proves nothing. PathMRI samples seconds apart, because movement is the proof — and where it only manages one sample it makes no movement claim at all.

Security finding

The bypass, named

The firewall claims this flow for a tunnel and the forwarding decision does not use one. Asserted only from the node that terminates the tunnel; from anywhere else it downgrades itself, because "we have not shown it" and "it is leaking" are different sentences.

"The VPN is up but the app hangs"

Tunnel overhead plus a filtered ICMP means the handshake succeeds and the first full-sized response vanishes forever. PathMRI sends don't-fragment probes of two sizes down the same path and keeps four outcomes apart: delivered, fragmentation needed, the sender's own limit, and the black hole.

A control probe must pass and the failure must repeat before anything is reported — and no MTU is ever quoted that the probe did not bracket. A number nobody measured is worse than none.

Honest about what a tunnel hides

A tunnel collapses many physical hops into one logical hop, so every path view says the same sentence: verified to the tunnel ingress, opaque within, resumes at the far end.

Nothing inside that span is claimed as mapped, and no device inside it is ruled in or out. It is the difference between a diagram and evidence.

Where it works

Tunnel configuration is read from every firewall vendor PathMRI supports, each through its own API or CLI — and site-to-site tunnels in AWS.

Palo Alto PAN-OS· Fortinet FortiGate· Cisco ASA· Cisco FTD· Check Point· Juniper SRX· pfSense / OPNsense· VyOS· AWS site-to-site

Next