Azure IP Flow Verify Says Allowed, but the VPN Still Fails

Site-to-site tunnel connected, VM healthy, on-premises client gets nothing. You open Network Watcher, run IP flow verify, and it says Access allowed, so the ticket gets closed as a VPN problem. That result does not mean what it looks like, because IP flow verify evaluates the security rules for the flow you described and never tests whether Azure has a route to your on-premises prefix.

The filtering question and the routing question are separate, and Network Watcher answers them with different tools. Knowing which one you asked is most of the diagnosis.

What IP flow verify actually decides

IP flow verify takes a VM, a network interface, a direction, five-tuple values and a protocol, then reports the NSG and security-admin rule decision for that flow. It works on TCP and UDP, so it is not an ICMP rule tester and a blocked ping proves nothing about your service. Feed it the real flow rather than a guess. An inbound connection from on-premises to a database port is a different description than an outbound connection the VM initiates.

If the gateway translates addresses, use the source address that reaches the boundary you are evaluating, not the one in the client config. Read the result for what it is, too. Access allowed means the filter layer would permit the packet if it arrived, and nothing more.

What it cannot tell you is the route Azure selected, whether the guest firewall allows the port, or whether anything is listening. Those live at other layers.

What next hop and effective routes add

Next hop answers a forwarding question: for this destination, which next-hop type Azure picks, at what address, from which route table. Effective routes list what the NIC actually has. Run both and you get the Azure-side path that a green IP flow verify leaves blank.

Microsoft's IP flow verify overview states the filtering scope directly, while the next-hop and route-diagnosis pages cover the forwarding side. Quote the right page when you write up the finding.

The commands are short enough to run from a shell. az network nic show-effective-route-table lists the routes applied to the interface. az network watcher show-next-hop with a source and destination returns the selected hop. Compare the prefix you care about against that table, then confirm which entry wins.

Walk the return path from the VM NIC

Do this from the target VM's NIC, for the on-premises client prefix, not for the internet. The return path is where site-to-site faults hide, because a tunnel-status check only reports that the security associations are up.

If the expected route is missing, check the remote prefixes the gateway configuration supplies, the VNet connectivity design and any route-propagation setting. A local network gateway object describes the on-premises side; its existence does not prove every required prefix is present and preferred at the NIC. Those are different facts, and only one of them shows up in a portal summary.

Read the next-hop type instead of copying an example

A managed VPN gateway path normally shows VirtualNetworkGateway as the next-hop type. VirtualAppliance describes a different forwarding design, usually a firewall or network virtual appliance.

Do not create an appliance route pointing at a guessed VPN endpoint because an old forum answer used that type. If a user-defined route overrides the intended path, find its owner and purpose before you change it. A second NIC can also change which interface the guest uses, and removing it may break another service instead of fixing this route.

Move to the boundary that still fails

When filtering and routing both match the design, the fault is elsewhere. Check the guest's own route table, its firewall and whether the listener is bound to the expected address. Then check the VPN's protected traffic selectors and the on-premises reply path. Each of those is a separate test with a separate result.

Close with a permitted application request and observations from both ends. An allow result and a correct next hop are two pieces of evidence, not proof that the connection succeeded.