Azure Site VPN Monitoring: Pair Tunnel State With a Real Probe

Every dashboard is green, the tunnel has been up for eleven days, and the branch cannot load the internal application. That is the symptom this design exists for, and it is not a monitoring bug. Tunnel state answers a question about negotiation, while the user is asking a question about a request crossing four routing decisions and a policy layer. You need both signals, kept separate, and a way to tell them apart at three in the morning.

Start from the failing symptom, not the tunnel

An established security association means the peers agreed on a proposal and installed keys. It does not mean the selectors cover the subnet the user needs, that the far side has a return route, or that a firewall accepts the port after decryption. Traffic can also fail on the branch side of the tunnel, in which case Azure sees nothing at all and reports perfect health. The tunnel metric is necessary, and it is never sufficient.

Three states have to be distinguishable: the tunnel is down, the tunnel is up and the service fails, and the monitoring source itself is unavailable.

Put the probe where the users are

For a branch-to-Azure application, run the synthetic test from a host in the branch workload network and point it at the private HTTPS entry point users actually hit. A probe launched from the gateway uses a different source address and often a different policy path, so it can pass while every user fails. Azure Connection Monitor supports TCP, ICMP and HTTP checks with test groups and thresholds, and its on-premises sources have agent requirements that differ from the Azure-side ones. Check the current supported arrangement rather than copying a retired classic monitor recipe from a blog.

Keep the probe narrow and boring: one destination, one port, a frequency that matches the operating requirement, and an explicit allow rule for that source.

Choose a check that matches the service

A TCP connect to the service port proves transport reachability through the tunnel and tells you nothing about TLS or the application. An HTTP check adds a status expectation and catches a listener that accepts connections but cannot serve, which is the more common failure after a certificate or backend change. Neither one is an authenticated business transaction unless the test actually authenticates, so do not label it as one on the dashboard. Pick the check that fails when the user's complaint happens.

ICMP is the weakest option of the three, since plenty of stacks drop it by policy and a failed ping proves very little.

Get both signals into Elastic without inventing them

The VPN gateway emits platform metrics such as tunnel egress and ingress bytes and packet drop counters, and it can send diagnostic logs in categories including tunnel and IKE events. Connection Monitor results arrive through Azure Monitor as metrics and through a Log Analytics workspace as log records. None of that appears in an Elastic index by itself. Choose one supported pipeline for metrics and one for logs, usually the Azure Event Hub input or the Azure Monitor integration, and verify what the installed integration actually ingests before you trust the index pattern.

Retain the labels that let an operator join the two datasets: source endpoint, destination, protocol and port for the probe, and tunnel identity plus peer address for the gateway.

Validate the pipeline with one controlled event, then search for it in Elastic and check its timestamp and resource labels. A document with the wrong timestamp is worse than a missing one, because it makes stale data look current.

Alert on the difference, not the colour

The point of keeping two signals is the combinations. Tunnel down should page the network owner; tunnel up with a failing probe should page the application owner; a missing probe result should page whoever owns the monitoring agent. Collapsing all three into one red panel guarantees that the alert gets muted within a month. Alert on sustained failure with a persistence window rather than on a single sample, and add a separate check for the health of the ingestion pipeline itself.

A dashboard full of yesterday's passing samples should not read as a healthy path today.

Written down, the contract is small: the tunnel metric tells you the gateway negotiated, the probe tells you the path works from where users sit, and the pipeline health tells you whether either answer is current. Everything else on the dashboard is commentary.