Azure S2S VPN Connected but No Traffic: Read the IKE Log

The portal says Connected, the tunnel has an uptime counter, and a trace from your virtual machine dies on the second hop. Connection state describes the IKE and IPsec negotiation, not whether a single packet survives the policy layer on either side. Two faults account for most of these tickets, and neither one is repaired by changing an Azure route. Both are already written down in the log the gateway produced, which is why I start there instead of in the route table.

What Connected actually certifies

A connected site-to-site connection means phase 1 and phase 2 completed and the security associations are up. That is a statement about negotiation: both peers agreed on a proposal, exchanged keys, and installed the pair of SAs. It says nothing about whether the traffic selectors match the subnets you believe are protected, and nothing about whether the far side will route the packet anywhere after it decrypts. A tunnel can stay up for weeks while dropping every interesting flow, which is exactly the pattern that makes people rebuild a healthy gateway.

The two faults worth checking first are a peer proposing AH instead of ESP, and a virtual network numbered in a space the gateway will not treat as internal.

Open the exported log before touching routes

In the portal, open the virtual network gateway and run the VPN troubleshoot operation against the connection, then download the bundle it produces and unpack it. Inside is an IKE log with the phase 1 and phase 2 exchanges, timestamped and readable as plain text. Search it for the transform line rather than reading top to bottom, because the interesting entry is usually a few hundred lines in. If you have no portal access, the same diagnostics appear in the gateway's log destination when diagnostic settings are enabled.

Two entries carry most of the value. The first reads along the lines of expected ESP with combined authentication and cipher, received AH. The second is an invalid payload error during the IKE exchange, which usually means a malformed or unsupported proposal field.

Both describe what the on-premises device offered, so both are peer-side settings. Regenerating the Azure side of the connection does not change the proposal your firewall sends, and doing it anyway is the most common wasted hour in this workflow. On the peer, set phase 2 to ESP with combined authentication and cipher and let it negotiate the algorithm, then check whether a vendor checkbox labelled something like combined mode is silently selecting an AH proposal underneath.

Confirm the virtual network address space

The gateway expects the virtual network to sit in private ranges. A network numbered in a public block, for example starting 111.x, can bring the tunnel up while Azure declines to treat that space as internal, so the connection looks healthy and no flow is accepted. Confirm the address space before you spend an afternoon on selectors. If the numbering is a hard requirement from an older allocation, the fix is an address plan change rather than a different gateway.

Record the overlap with the on-premises ranges while you are in the address space blade, because overlapping prefixes produce a different failure that looks similar from the client.

Verify the prefixes in both directions

The local network gateway resource holds the on-premises prefixes, and they have to match the subnets the remote device actually protects. A summary that includes addresses the device drops will pass some flows and fail others, which reads like an intermittent routing fault rather than a configuration mismatch. Check the far side as well: one end listing a /16 while the other lists three /24s inside it is the classic partial failure. Neither list is authoritative on its own, so compare them side by side instead of trusting the one you can see.

Changing a prefix is not always picked up on its own, so plan to re-save or recreate the connection object and then confirm the new prefixes appear on both sides.

Test a path, not a ping

The trace that separates a working tunnel from a working route looks like this: first hop is the on-premises gateway, then a few unresponsive hops, then the remote host answers. If the trace never reaches the host, test the TCP port the application actually uses, because ICMP is filtered often enough that a failed ping proves very little. Run the same trace from a remote host toward a virtual machine in Azure. Asymmetry between the two results is the fastest way to find a missing return route or a rule that permits one direction only.

Write the peer proposal, both address spaces and the connection creation time into the ticket, so the next engineer knows which values were rebuilt and which were never touched.

If the log comes back empty, the gateway may not be terminating your connection at all. Confirm that the peer address on the local network gateway matches the device you are reading the log from, since two gateways in one subscription are easy to confuse during a rebuild. That mistake costs a day and leaves no trace in any log.