Azure VM Persistent Route help

Question

Hi

I hope to get some advice on a routing issue from Azure to an on-premises system.

A little background first, please bear with me:

We have an on-premises VM that connects to an isolated Thirdparty network via an On-Prem Cisco ASA FW specifically for this purpose.

---

OnPrem VM's IP: 10.XXX.23/24 

OnPrem dedicated FW - Local Inside Interface IP: 10.XXXX.190

---

OnPrem dedicated FW - 3rdParty Interface IP: 10.XXXX137

Thirdparty router IP: 10.xxx.138 - This routes to aditional devices on 10.XXX.10 and 20.xx.10.

---

There are static routes configured for 3rd party FW interface using:

3rdParty Interface - 10.xxx.10 255.xxx.255 - 10.xx.138 (Gateway IP)

3rdParty Interface - 20.xxx.10 255.xx.255 - 10.xxx.138 (Gateway IP)

---

The on-premises VM (10.xx.23) has persistent routes added to allow connectivity:

Network Address          Netmask               Gateway Address     Metric

10.xx.10                255.255.255.255       10.xx.190            1

20.1xx.10                255.255.255.255       10.xx.190            1

10.xx.136            255.255.255.252       10xx.190            1

---

The above works fine on-prem but I now need to migrate the On-Prem VM service into Azure.

Azure Side

I have created a test Azure VM with a static IP in an isolated subnet (no other devices using it) in the Production subscription of our LZ (Hub and Spoke topology).

We have a site-to-site VPN connected to our on-premises FW using a VPN Gateway configured in the Connectivity subscription of our LZ (as expected).

We have defined subnets for on-premises address spaces in the Local Network Gateway:

10.xx.0/24, 10.xxx.0/24, 10.xx.0/24, 10.xx.0/24 (Local Subnets) and 172.xxx0 (VPN client Subnet)

---

Main Problem that I'm requesting advice for:

When I add the defined persistent routes on the Azure VM (IP address: 10.150.1.10/24) as is on the On-Prem VM

Network Address          Netmask               Gateway Address     Metric

10.xxx.10                255.5xx.255       10.xx.190            1

20.xxx.10                255.2xx.255       10.1xx.190            1

10.xx5.136            255.xxx5.252       10xx.190            1

I'm unable to ping the 10.xx.10 and 20.1xxx7.10 addresses, even though the routes have been added by the 3rd party on their network side.

All Network Objects, static routes, groups and rules are duplicated on the ASA FW for the Azure VM as is for the On-Prem VM and I can access/ping the ASA FW inside interface no problem .

Is there a specific way I need to route the persistent routes from Azure side, have I missed something in the configuration above to get the connectivity I require?

Please all advice is welcomed!

Thank you

Nitrox

Answer 1

Hi @ Nitrox,

Welcome to Microsoft Q&A Platform.

You’re on the right track trying to mirror your on-premises routing in Azure. However, in Azure, OS-level static routes inside the VM do not override Azure fabric routing, so using User Defined Routes (UDRs) is the correct approach.

That said, based on your latest validation:

UDRs are configured and applied

Local Network Gateway is advertising the correct prefixes

You are able to successfully ping the ASA inside interface (10.100.10.x)

This confirms that:

• The Site-to-Site VPN connection is established and functioning correctly
• Azure is correctly routing traffic to your on-premises network.

Since Azure can successfully reach the ASA, the VPN and Azure routing are functioning correctly. The issue is most likely related to return routing, NAT, or firewall configuration beyond the ASA in the on-premises or third-party network path.

If the above steps did not help resolve your issue, please feel free to share the details in a private message so we can proceed with further troubleshooting over a Teams call. I am happy to connect with you on Teams to investigate and resolve the issue.
Pleaseand “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

Azure VMs cannot use in-guest persistent routes to bypass Azure’s own routing. Azure routing is determined by:

• System routes (for VNet, peering, Internet, VPN, etc.)
• Custom/user-defined routes (UDRs) on the subnet
• BGP routes from the VPN gateway/ExpressRoute

In-guest routes on the Azure VM are ignored for how packets leave the VM’s NIC; they only affect routing inside the guest after Azure has already decided the next hop. To reach 10.10.227.10 and 20.10.227.10 via the on-premises ASA, Azure must see those prefixes as reachable through the VPN gateway, not via a host route on the VM.

Key points and checks based on the scenario:

1. Ensure Azure knows the 10.10.227.10/32 and 20.10.227.10/32 prefixes
   • These addresses are not in the current on-premises address spaces configured on the Local Network Gateway (10.100.10.0/24, 10.100.11.0/24, 10.100.13.0/24, 10.100.14.0/24, 172.16.50.0/24).
   • Add the 10.10.227.10 and 20.10.227.10 networks (or their containing prefixes) to the on-premises address space advertised to Azure (via Local Network Gateway or BGP), so that:
     • Azure VPN gateway learns routes to 10.10.227.10 and 20.10.227.10.
     • Those routes are then propagated into the VNet as effective routes with next hop = VPN Gateway.
2. Use effective routes on the Azure VM NIC to verify
   • In the Azure portal, open the VM → Networking → select the NIC → under Help, select Effective routes.
   • Confirm there is a route for 10.10.227.10 and 20.10.227.10 with next hop type VPN Gateway (or a more specific on-prem prefix that covers them).
   • If there is no such route, Azure will not send traffic for those IPs over the VPN, regardless of in-guest persistent routes.
3. Avoid relying on in-guest persistent routes for Azure → on-prem routing
   • Azure uses longest prefix match across system, BGP, and custom routes to choose the next hop.
   • The correct place to steer traffic is:
     • On-prem: static routes on the ASA and routers (already in place).
     • Azure: on the VPN gateway (via Local Network Gateway/BGP) and, if needed, subnet-level UDRs.
   • Do not try to point the Azure VM directly at 10.100.10.190 as a gateway; the VM’s default gateway must remain the Azure-provided VNet gateway (the subnet’s .1 address managed by Azure).
4. Check for forced tunneling or conflicting 0.0.0.0/0 routes
   • If any custom route or BGP route to 0.0.0.0/0 exists, it may force all traffic (including to 10.10.227.10/20.10.227.10) to a different next hop (NVA, VPN, etc.).
   • Use effective routes to confirm that the longest prefix for 10.10.227.10 and 20.10.227.10 is indeed the on-prem route via VPN gateway, not a generic 0.0.0.0/0 or other conflicting prefix.
5. If a network virtual appliance (NVA) is used in Azure
   • If traffic is intentionally routed via an Azure NVA (Virtual Appliance next hop), ensure IP forwarding is enabled on the NVA NIC and in its OS; otherwise packets will be dropped.

Summary of what to change:

• Do not rely on the persistent routes inside the Azure VM to 10.100.10.190.
• Add/advertise the 10.10.227.10 and 20.10.227.10 networks (or their containing prefixes) to Azure via the Local Network Gateway/BGP so that the VPN gateway exposes them as effective routes.
• Verify via the VM NIC’s effective routes that those prefixes use the VPN gateway as next hop.
• Once Azure routing is correct, the existing ASA static routes and rules should allow the same connectivity as from the on-prem VM.

---

References:

• Diagnose a virtual machine routing problem
• Diagnose a virtual machine network routing problem using the Azure portal
• Tutorial: Diagnose a virtual machine network routing problem using the Azure portal