Azure VM Can't Reach IMDS or WireServer After the VPN Starts

The VM is up, the VPN client says connected, and the Azure agent starts reporting unhealthy a few minutes later. Sometimes SSH survives and Run Command from the portal does not, which sends people looking at the agent instead of at the route table. The guest's own forwarding decisions changed when the tunnel came up, and two platform addresses are usually the first casualties. I treat that as a routing symptom before I treat it as an agent failure.

The symptom looks like a broken agent

Both addresses below get proposed as a fix, and they are not the same service. Copying a /32 for one of them because it worked for the other is how a temporary workaround turns into permanent configuration nobody dares remove.

The order that works is to confirm which address the failing call actually targets, then read how the guest resolves it. Anything else is guessing with extra steps and a longer change window.

168.63.129.16 is not a public destination

168.63.129.16 is Azure's special virtual platform address, and one of its roles is WireServer, which the VM agent uses to talk to the fabric. Microsoft documents that agent traffic to TCP ports 80 and 32526 has to stay available. It is not an ordinary internet host, and it is not something a full-tunnel VPN should be carrying to a remote exit. That is why a tunnel that looks healthy can still starve the agent.

The platform address documentation also says this address is not subject to user-defined routes, which is an Azure-fabric property rather than a promise about your guest. A local firewall rule or a VPN client's own routing policy can still break the path, and neither of those lives in the VNet's route table.

If the agent is the thing reporting trouble, check the service state and the path to that address before you reinstall anything.

169.254.169.254 has its own rules

169.254.169.254 is the link-local address for the Azure Instance Metadata Service. Requests to it have requirements of their own: the primary NIC and primary IP, a DHCP configuration that supports the address, and bypass of any HTTP proxy. Sending them through a remote VPN exit or an arbitrary internet gateway is not the access model Microsoft describes.

That proxy clause catches people who fixed the route and still see failures. A guest HTTP proxy can break IMDS while ip route get returns exactly the interface you expect, so check the proxy exclusions as well as the routes.

Do not paste metadata responses into a support ticket while you debug this. They can carry credentials and instance detail that outlive the incident.

Read the guest's policy routing, not just the main table

On a Linux guest, three read-only commands separate the layers: ip -4 rule show for the policy rules, then ip -4 route get 168.63.129.16 and ip -4 route get 169.254.169.254 for the decisions the kernel actually makes. Run them before and after the VPN connects. The difference between those two outputs is your change set, and it is more useful than any guess about what the client did.

A VPN client that installs policy rules can leave the main table untouched while still redirecting those lookups. That is why a main-table-only fix appears to work on one host and does nothing on the next. Multi-NIC guests add the same problem from the other direction, because the answer depends on which NIC and source address the rule selects.

Resist the recipe that adds both /32 routes through the old gateway. A link-local platform path and a general WAN next hop are different objects, and a blanket exception hides the real policy conflict.

Keep administration and recovery separate

Your SSH or RDP reply can be captured by a full-tunnel default as well, but it targets the administrator's observed address rather than either platform endpoint. Diagnose it from its own request and reply pair, and keep an independent recovery channel such as the serial console before you change VPN policy. If a deployment restarts the VM and the agent reports unhealthy, inspect the recorded action and the responsible service instead of assuming the route change caused the reboot.

Then verify the three flows separately: the private resource you actually wanted, the supported agent and platform communication, and the administration path. Restoring one of them is not evidence that the other two survived.

Write the approved exception under whoever owns the guest network and VPN configuration, including what happens on reconnect and restart. Azure UDRs are not the guest's route table, and editing them will not fix a local policy rule.