Once the route was propagated, things worked as expected. The on-prem network admins had not propagated those routes so the Azure ExpressRoute Gateway did not have a route to send clients responses to. When we looked at the propagated BGP routes (via ExpressRoute) then we saw the client subnets were not included in the Route Table. We verified that everything in Azure was correct.
I had one such scenario where a system in Azure was “not-accessible”. The other big cause is that the on-premises edge firewall doesn’t allow the traffic – this is the #1 cause of RDP/SSH to Azure virtual machines not working, in my experience. And I have found that this is often overlooked and people start saying things like “Azure networking is broken” when they haven’t sent a route to Azure so that the Azure resources connected to the virtual network(s) can respond.
#VIRTUAL GATEWAY HOW TO#
The other part of that story is that Azure needs to know how to send packets back to on-premises – this affects responses and requests.
They add a route entry to that CIDR block on their VPN/ExpressRoute edge device and packets can now get to Azure.
Routing to Azure is often easy your network admins allocate you a block of private address space on the “WAN” and you use it for your virtual network(s). An important step of verifying or troubleshooting communications over ExpressRoute is checking that all the required routes to get to on-premises or WAN subnets have been propagated by BGP to your ExpressRoute Virtual Network Gateway (and the connected virtual networks) by the on-premises edge router.
0 kommentar(er)
