On-prem to Azure VM Connectivity Issue via ExpressRoute

krutibasa majhi 25 Reputation points
2026-07-21T08:07:10.3633333+00:00

Hi all,

I have the following Azure network design:

On-prem → ExpressRoute → ERC VNet → Hub VNet (FortiGate behind ILB) → Spoke VNet

The ExpressRoute Gateway is deployed in the ERC VNet, which is peered with the Hub VNet where the Azure FortiGate is deployed behind an Internal Load Balancer (ILB). BGP is configured between the on-prem FortiGate and the Azure FortiGate.

To steer on-prem traffic through the Azure FortiGate, I have attached a route table to the ExpressRoute Gateway subnet in the ERC VNet. The route table contains a route for 10.3.0.0/20 with the next hop set to the FortiGate ILB (10.0.5.68).

Working scenario

I have a DEV VNet that is peered with both the ERC VNet and the Hub VNet. With the same routing design, on-prem connectivity to the DEV VNet works as expected.

Non-working scenario

I have another spoke VNet (10.3.0.0/20) that is peered only with the Hub VNet. The spoke subnet also has a UDR pointing traffic to the FortiGate ILB (10.0.5.68).

However, on-prem cannot reach the VM (10.3.0.36) in this spoke VNet.

Question

Should this design work when the spoke VNet is peered only with the Hub VNet, or is peering with the ERC VNet also required? If the design is supported, what Azure routing or peering configuration should I verify?

Thanks in advance for your guidance.

Krutibasa

Azure ExpressRoute
Azure ExpressRoute

An Azure service that provides private connections between Azure datacenters and infrastructure, either on premises or in a colocation environment.

0 comments

1 answer

Sort by: Newest
Most helpful Newest Oldest
  1. Michele Ariis 7,315 Reputation points MVP Volunteer Moderator
    2026-07-21T08:33:21.59+00:00

    Hi Krutibasa; the spoke VNet does not necessarily need direct peering with the ERC VNet; the design can work with ERC VNet - Hub VNet - FortiGate - Spoke VNet; however, VNet peering is not transitive, so every part of the path must be explicitly handled by the FortiGate and the route tables;

    I would verify the following:

    On both the ERC-to-Hub and Hub-to-Spoke peerings, enable Allow forwarded traffic in both directions; this is required because the packets reaching the spoke are being forwarded by the FortiGate rather than originating directly from the Hub VNet.

    Confirm that the on-premises environment has a route for 10.3.0.0/20 pointing through ExpressRoute; the ExpressRoute gateway will not automatically learn or advertise a VNet that is only indirectly connected through another peering; if the prefix is being advertised by the Azure FortiGate through BGP, verify that it is actually present in the on-prem FortiGate routing table.

    Check the effective routes on the VM NIC for 10.3.0.36; the on-premises prefixes should use the FortiGate ILB as the next hop; also verify the effective routes on the FortiGate NICs and the ExpressRoute GatewaySubnet route table.

    Make sure the FortiGate has a route for 10.3.0.0/20 through the Hub-to-Spoke peering and that the ILB configuration supports the forwarding scenario, typically using HA Ports and Floating IP where required by the FortiGate design.

    Finally, verify NSGs, FortiGate policies, asymmetric routing and source NAT; SNAT can hide routing problems during testing, while without SNAT both directions must have a valid and symmetric route.

    The reason the DEV VNet works may be that its direct peering with the ERC VNet allows its prefix to be visible to the ExpressRoute gateway; the second spoke does not have that direct visibility; therefore, direct peering with the ERC VNet is not mandatory, but the spoke prefix must still be advertised to on-premises and all peerings must allow forwarded traffic.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.