TunnelCheck

A site-to-site tunnel comes up and both ends can ping each other. Then file copies stall, a remote desktop freezes on its first full screen, and the link drops every few minutes for no reason anyone can name. The tunnel is declared healthy, the firewall is declared healthy, and the problem has not moved — because it was never in either of them. It was in the path, and nobody measured the path.

Why I built it

Because the question that decides a VPN design is usually asked too late. Whether a path will carry a tunnel is normally found out by building the tunnel and watching what breaks, and by then the design has been quoted, the equipment chosen and the change window booked. Everything that goes wrong afterwards gets argued about as a fault in the VPN, when it is a property of the network underneath — one that could have been measured in a few minutes beforehand.

The tools that exist answer neighbouring questions. A throughput tester says how fast, a ping says whether, a port scanner says what one end can see. None of them measures the path in each direction, says how the NAT in the middle behaves, or works out the numbers to configure. And like McastTool, it has to run on whatever machine is available at each end, usually one you do not control — so it is a single Windows file with no runtime and no installer.

The problem

Most VPN faults are not encryption faults. When the tunnel is up and the application still fails, the cause is almost always one of four things, and all four belong to the path:

• The path drops large packets silently. Small packets cross, so ping succeeds and the application fails. Path MTU discovery is meant to catch this and does not, because it depends on ICMP that is filtered more often than not — and the limit can differ in each direction.
• The NAT in the middle does not behave predictably. If it hands out a different outside port for every destination, the far end cannot know where to send, and a direct tunnel cannot be built at all. Carrier-grade NAT makes that the common case rather than the exception.
• The firewall passes one protocol and not another. IPsec needs UDP 4500 to cross NAT; WireGuard needs its own UDP port. Either can be blocked while everything else works.
• The NAT forgets the connection faster than the keepalive. The tunnel drops every few minutes, recovers on its own, and nobody can say why.

Each of these is cheap to measure before a design is quoted and expensive to discover after it has been built.

What I did

• One window, both ends. The same program runs at each end of the link: Test a path at the near end, Answer for the far end at the other. Because both ends are the same known-good tool, whatever goes wrong is the path.
• Path MTU in each direction, separately. The largest packet that crosses without fragmenting, measured both ways, because an asymmetric limit is exactly the fault a one-way test misses.
• NAT behaviour. Whether the outside port stays the same for every destination or changes per destination, and whether carrier-grade NAT is in the way — which decides between a direct tunnel and a relay.
• The ports that actually cross. UDP 51820, 51821, 500, 4500 and 1194, and TCP 443 and 80 by default, each reported as passing, blocked or not tested. A port the far end could not open is shown as untested and never as blocked: inventing a network fault out of the tool’s own gap would be worse than saying nothing.
• How long a quiet connection survives, as an optional test of a few minutes, so the keepalive interval is a measurement rather than a folklore value.
• Loss, jitter and reordering at 1,228-byte packets — the size a tunnel actually sends, not the small packets a ping uses.
• The numbers to configure, with the working shown. Tunnel MTU (path MTU less 60 for WireGuard), TCP MSS clamp (tunnel MTU less 40) and keepalive (half the longest idle survival), with a green, red or grey line for WireGuard, IPsec and OpenVPN.
• One file, no runtime, no installer. Testing needs no administrator rights, it talks only to the address it is given, and it has a command line as well as the window, so a measurement can be scripted and repeated.

The result

The design starts from measurements instead of assumptions. Before a tunnel is quoted, the path has been asked what it will carry, in both directions, and the answer arrives as the configuration to use: the MTU, the MSS clamp, the keepalive, and which of WireGuard, IPsec and OpenVPN the path will actually pass. When the finding is that the path needs work before any VPN will be reliable on it, that is said plainly — before anything has been bought.

It also makes a fix provable. The same test is run again after a change, so an MTU that is said to be fixed either crosses at the new size or does not, and a firewall rule that is said to be open either shows the port passing or does not.

The boundary: both ends run on Windows, so a Linux far end means running the answering copy on a Windows machine at that site. It is not a throughput tester — iperf already does that well — and it takes one measurement at one moment, which its own report says.

Like the other tools here, it exists because a network problem needed measuring and the available options answered a different question. The value is in the diagnosis; the software is the instrument that made it possible.