Routing Issue VNet to Vnet Peering with Site to Site VPN's on both

Highlighted
Occasional Contributor

Hello I have a VNET with a site to site VPN to my main office and I have a Second VNET with a site to site VPN to my second office. I need the second office to communicate with VM in the first VNET and I have setup VNET Peering but I can ping the VMs in the first VNET from the my second office.

 

Any thoughts? 

 

              VNET1 --------------VNET Peering--------------VNET2

                ^                                                                      ^

Site to Site VPN(Main office)                      Site to Site VPN( Second office)

7 Replies
Highlighted

Hi @Berkata14 

 

I'm afraid the setup you have cannot work. When you peer two VNets, you can configure gateway transit on one of them (to utilize the second VNet's VPN gateway), but that first VNet cannot host its own gateway. More details can be found here.

 

You can redesign your network to use 'Hub-and-Spoke' model (have one Hub VNet with VPN gateway), where you:

  • either utilize some existing connectivity between your offices (your WAN),
  • or if they are not connected together, you can have one IPSec tunnel from each office to the Hub.

You can then peer that hub with several VNet spokes (they can be in different regions) and configure 'remote gateway' in the peerings (from the spokes' side). More details about such setup here.

 

Another option (more advanced but also more expensive) is Azure Virtual WAN, where you could even achieve connectivity between your remote offices and VNets in a mesh-like topology, effectively using Azure backbone network as your transit network (WAN).

 

Highlighted

@David Pazdera Thanks for the reply David.

 

The problem I was trying to solve with the VNET Peering is that, I have two locations "office1" and "office2" which are connect via site to site vpn, I have a site to site vpn going from office1 to the azure VNET. On the Azure VNET I have VM servers and I need "office2" to be able to communicate with these servers. The problem is due to the limitation of the on prem networking equipment which can only use IKE1 I can only have 1 site to site going to the azure VNET. Is there any way to have office2 communicate with the Azure VNET?

 

             VNET

                ^   

                 |

                v

                                                                  

Site to Site VPN(Main office) <------------------- > Site to Site VPN( Second office)

Highlighted

I see @Berkata14 

 

Since your two sites are connected together over VPN, and your primary site has a S2S VPN connection established with your VNet, the problem could be in a few places:

  • have you checked there is no overlap in IP ranges anywhere in your network?
  • when you created a "Local Gateway" resource that represents your on-prem environment, did you include IP ranges from both offices, so Azure VNet can learn those prefixes?
  • Are you hosting your VMs in the same VNet where your VPN Gateway is placed or is it a separate VNet? If separate, it is worth checking 'gateway transit' setup in both peering objects.
  • When you traceroute Azure VM address from your Second office, can you see the traffic reaching Azure? If not, your VPN device in the Second office might not know where to send this traffic (I guess you are using static routing).
  • Can you reach Azure VM from the Main office? If yes, the Azure side seems to be configured correctly (but please validate that Local Gateway configuration)

That's probably all potential problem areas I could think of.

Highlighted

@David Pazdera 

 

  • have you checked there is no overlap in IP ranges anywhere in your network?

NO Overlap

 

  • when you created a "Local Gateway" resource that represents your on-prem environment, did you include IP ranges from both offices, so Azure VNet can learn those prefixes?

Yes the IP range for the second office is included in the local gateway

 

  • Are you hosting your VMs in the same VNet where your VPN Gateway is placed or is it a separate VNet? If separate, it is worth checking 'gateway transit' setup in both peering objects.

The VM are in the Same VNet where the VPN Gateway is. 

 

  • When you traceroute Azure VM address from your Second office, can you see the traffic reaching Azure? If not, your VPN device in the Second office might not know where to send this traffic (I guess you are using static routing).

Cant reach the VM through TRACERT, Correct its policy based static IKE1. Thats why I cant create a second site to site from office 2 to Azure. 

 

  • Can you reach Azure VM from the Main office? If yes, the Azure side seems to be configured correctly (but please validate that Local Gateway configuration)

Yes I can reach the VMs from the main office and the the local Gateway does have the IP range for the second office.

 

Any other suggestions? 

Highlighted

@David Pazdera 

 

1. No Overlap in IP ranges 

2.The Local Gateway resource has the IP ranges for both offices

3. The VM's are in the same VNet the VPN Gateway is in. 

4.TRACERT from the second office does not reach the azure VM's 

5. I can reach the Azure VM's from the main office. 

 

Any other ideas?

Highlighted

Thanks @Berkata14 

 

It seems you have configured everything correctly on the Azure side. I assume you also checked your NSGs and any on-premises firewall "in the way", if they are not blocking the traffic.

 

How did you configure routing in your Second office? Have you added the Azure range as a static route with your Main office VPN GW as the next hop? In other words, from your TRACERT (Second office --> Azure), are you reaching your VPN device in the Main office or where does the traffic end?

 

You could check effective routes on your Azure VM to see, how it handles any calls from/to your Second office IP range.

 

Apart from that, I'm running out of ideas, but I suspect it is a routing problem inside your on-premises network.

Highlighted

I would agree with @David Pazdera, apparently the issue is most probably related to a routing configuration on your on-premises network. 

 

My advise to you is to double check the configuration and re-run your tests.