Peer (or route) two local network gateways in Azure?

A more comprehensive description of your setup would provide more clarity. Are you using ExpressRoute? Site-to-Site VPN?

1: What is the configuration of your local network gateway? You might just need to add more prefixes:

https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-create-site-to-site-rm-powershell#code-try-22

$local = Get-AzLocalNetworkGateway -Name Site1 -ResourceGroupName TestRG1
Set-AzLocalNetworkGateway -LocalNetworkGateway $local -AddressPrefix @('10.101.0.0/24','10.101.1.0/24','10.101.2.0/24')

Select allOpen in new window

2: On your Site-to-Site VPN Gateway configuration, check the Client Address Space:

https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-site-to-site-classic-portal

Client Address space: List the IP address ranges that you want routed to the local on-premises network through this gateway. You can add multiple address space ranges. Make sure that the ranges you specify here do not overlap with ranges of other networks your virtual network connects to, or with the address ranges of the virtual network itself

Mlanda and Daryl - thank you for your replies.  I forgot to mention that the two on-prem networks are supported by two separate ISPs (a form of redundancy for the office) and therefore have two separate public IPs that must use the Azure VPN Gateway.  I have the two Local Network Gateways inside the Connections area of the VPN Gateway.  Our on-prem firewall is VPNing into Azure on both connections, but only on-prem network A (10.10.x.x) can talk to the Azure assets.  On-prem network B (10.20.x.x) reaches the Azure VPN Gateway, but that is all.  I need the two Azure Local Network Gateways to talk to one another.

So you have two on-prem networks, each connected to a different Internet connection (provided by different ISPs) and just the one router?

"and therefore have two separate public IPs that must use the Azure VPN Gateway."

In this case, I think you need to think of each of these networks as a separate site altogether. You would therefore need separate IPsec VPN tunnels.

(Source: https://learn.microsoft.com/en-us/azure/vpn-gateway/design)

Daryl - yes, two on-prem networks that come into two different ports on the firewall.  From the firewall, we have rules to forward traffic (or certain types of traffic) to either on-prem or Azure resources.  Could I simply develop a firewall rules to forward all traffic from one port to the other on the firewall and then send it up to Azure?  Yes, but I'm trying not to upset the apple cart and rewrite all of the rules we have that are working now.

Mlanda - this is almost EXACTLY where I am right now.  This tutorial is what I tried doing over this past weekend.  I have one Azure VPN gateway with two site tunnels and both tunnels are working.

In your example, I have 10.20.0.0/16 in a virtual network with the VPN gateway listed as a Connected Device and this is the virtual network that can talk to the on-prem assets.  The 10.21.0.0/16 is also a virtual network, but does NOT have the VPN gateway listed as a Connected Device.  This is why I tried peering and it didn't work.  I need 10.20.0.0/16 to talk to 10.21.0.0/16 and we should be good to go.

We're very close to solving this, but the last piece of the puzzle just escapes me.

Daryl - yes.  Network A goes out on one public IP and Network B goes out on another public IP.  The firewall pushes both networks up through their public IPs to Azure through the S2S Local Network Gateways, but that is where the traffic dies.

Currently, the Local Network Gateways ONLY have the public IP and private ranges of their respective networks.

"Currently, the Local Network Gateways ONLY have the public IP and private ranges of their respective networks. "

That's how it should be.

Are the VPNs on your on-prem router set up as policy based or route based?

Route based.

In your example, I have 10.20.0.0/16 in a virtual network with the VPN gateway listed as a Connected Device and this is the virtual network that can talk to the on-prem assets.  The 10.21.0.0/16 is also a virtual network, but does NOT have the VPN gateway listed as a Connected Device.  This is why I tried peering and it didn't work.  I need 10.20.0.0/16 to talk to 10.21.0.0/16 and we should be good to go.

Ah, thanks. If I understand correctly now, this means that we do not have problems on-premise. We now just want to have multiple vNets on the Azure side? This is a hub and spoke architecture. Something like this diagram right (this time your on-premise networks are on the left)? You want to have a hub in the middle, have your on-premise connections reach this hub (whicih is where your VPN Gateway will sit), then you peer across multiple vNets. Some shared services can also be hosted within the hub vNet and you peer to another vNet. [I like diagrams, clearer than text]

(Source: https://docs.fortinet.com/document/fortigate-public-cloud/6.2.0/azure-administration-guide/724262/vwan-architecture-diagram)

Mlanda - LOL!  Well you just added a whole bunch of question marks above my head.  I was all good reviewing and following this tutorial until it got to the "deploying vWAN ARM" step.  Are all of these service account steps necessary if we aren't using Fortinet?

Oh no. Not saying user fortinet. But the basic pieces are there. An focusing on the architecture and had just been looking for something with a diagram that captures it nicely. Azure Virtual WAN, vNets, etc. 

Mlanda - no matter what I try, the multi-site VPN using the VWAN is not working.  Have you tried one of these before?  It doesn't allow for public IP's and therefore will not allow for VPN connections from the on-prem firewall.  It is near impossible to set up connections in the group because it wants to completely unhook everything in Azure to become active.  I'd like to run this thing as a test in case it doesn't work, but I am not having any success.