This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(22.400000000000002, 67%, 12%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ENE%3C/text%3E%3C/svg%3E)
Hi!
I'm facing connectivity issues with a Vnet peered to a Vnet with a gateway and a S2S connection to my on prem resources:
Vnet-test is peered to Vnet-hub
Vnet-hub has a Virtual Gateway deployed
Virtual Gateway is linked to my on prem gateway
The flow from on prem (or p2s connections) is working.
The flow from a VM in the Vnet-hub to on-prem resources is working.
The flow from a VM in Vnet-test to Vnet-hub is working.
The flow from a VM in Vnet-test to on-prem is blocked, but I don't know where.
The peering options are set like the following:
What did I miss? How to define the proper routing to make my resources in Vnet-test able to reach on-prem instances through the Virtual Gateway?
Thanks a lot!
Hello @Nicolas ESPIAU ,
Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.
I understand that you have enabled gateway transit in your peered Vnet to use the VPN gateway in the hub Vnet but are unable to access the on-prem resources from the peered vnet.
Could you please help with the below details?
1) Are there any UDRs associated to the subnets in your peered Vnet (Vnet-test)?
2) Could you check the effective routes for the VM in peered Vnet (Vnet-test) and validate if you are getting the on-premises routes?
Refer : https://learn.microsoft.com/en-us/azure/virtual-network/diagnose-network-routing-problem#diagnose-using-azure-portal
Regards,
Gita
Hi @GitaraniSharma-MSFT ,
First of all, thank you for answering.
I've checked what you asked:
Tell me if I'm wrong but it's exactly what's expected here?
On the vm side, when I try route -n I don't see all these routes. I guess it's normal since it's been handling on the Vnet side.
I've ran some diagnostics with Network Watcher.
Our Network Security Officer opened the flow from 10.1.0.0/16 but told me that they didn't detect any traffic.
I tried the same from a VM in the Vnet-hub and this time the test was ok (on prem resource was reachable) but they saw the traffic from the monitoring tools.
Hello @Nicolas ESPIAU ,
Is there any address space overlapping between your on-premises network and peered Vnet?
Also, I see the network watcher test above shows that it reaches the VPN gateway but then it fails.
Are there any NSGs on your GatewaySubnet?
Is this traffic allowed on your on-premises Firewall?
And the Site to Site VPN configuration on your on-premises should have both your hub Vnet and peered Vnet address spaces added, is it configured correctly?
Regards,
Gita
There is no overlapping between on-prem and any Vnet in Azure.
There is no NSG attached to the GatewaySubnet.
The traffic is allowed on our on-prem Firewall.
For the last part, I'll have to double check with our Network Engineer, he told me that everything was configured properly but I'll make him check once again.
Hello @Nicolas ESPIAU ,
Could you please provide an update on this post?
Is the issue still persisting?
Regards,
Gita
Hello @Nicolas ESPIAU , do you have any new updates on this issue?
Hello @Nicolas ESPIAU , Could you please provide an update on this post?
Sorry for the late answer, I had no "reply" button so far.
We are still facing the same issue.
We tried to recreate the tunnel using the VTI and following the docs but it did not work, so to bypass this issue we had to mount 3 tunnels, for each VNet IP range.
Which is very annoying and we would like to make it work with only one tunnel and VTI conf.
Hello @Nicolas ESPIAU ,
Thank you for the update.
Could you please let me know what is the make and model of your on-prem VPN device?
Regards,
Gita
We're working with a Stormshield instance
Hello @Nicolas ESPIAU ,
Stormshield VPN is not an Azure validated VPN device.
If your device is not listed in the Validated VPN devices table, your device still may work with a Site-to-Site connection. The recommendation is to contact your device manufacturer for additional support and configuration instructions.
Refer : https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices
But I would advise you to collect packet captures from your VPN gateway to see what is causing this issue.
Refer : https://learn.microsoft.com/en-us/azure/vpn-gateway/packet-capture#start-packet-capture---portal
If that doesn't help, we may need to raise a support ticket to get further assistance on this issue. So if you have a support plan, I request you file a support ticket, else please do let us know, we will try and help you get a one-time free technical support.
Regards,
Gita
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(156.8, 70%, 25%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EHE%3C/text%3E%3C/svg%3E)
Hi I am having exactly the same problem, the peered VNET2 cannot communicate with the S2S vpn (peered Vnet1).
Effective route for the Virtual network gateway (transit gateway enabled) exist and correct, NSG with same cidr has been added also to inbound allow, just traffic doesnt seem to flow.
It looks like the VNet peering is not passing the traffic through, how to check vnet peering logs?
Hello @Ho, Eddie ,
Please check the below:
Regards,
Gita
Based on the details so far, this sounds like the peering was added after your VPN was created and your local site has no route to the peered VNET. Your quickest route to resolution is to delete and recreate the VPN Connection resource.
That may be a lead.
You mean delete the whole Virtual Gateway ? The Local Gateway ? Or just the Connection between the Virtual Gateway and the Local Gateway ?
Don't delete either gateway resource, just delete and recreate the Connection resource you have screenshotted. Ensure you have captured details like PSK and IPsec custom settings so you can recreate identically.
That's what I've done and it did change anything. I'm still investigating.
This would indicate an issue with the tunnel itself on-prem then. Check encapsulation settings and ensure any NAT settings are correct relative to spoke VNET
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(268.8, 96%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EC%3C/text%3E%3C/svg%3E)
We experience a comparable issue. What was ultimately the solution?
Hi I am having exactly the same problem, the peered VNET2 cannot communicate with the S2S vpn (peered Vnet1).
Effective route for the Virtual network gateway (transit gateway enabled) exist and correct, NSG with same cidr has been added also to inbound allow, just traffic doesnt seem to flow.
It looks like the VNet peering is not passing the traffic through, how to check vnet peering logs?
I also have a vm on VNet1 and it can talk to remote side of the VPN no problem, its the spoke side of the VNet (2) is the problem
Running a "connection troubleshoot", the next hop is for the public ip of the Azure VNG (see image)
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(284.8, 28.999999999999996%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESB%3C/text%3E%3C/svg%3E)
Would like to add that i experience a similar issue with the difference that i have a Fortigate NVA deployed in the HUB VNET where all traffic is passing through.
So the Virtual network gateway has a tunnel with an on-prem firewall and then has a UDR route for the spoke address range pointing to the NVA as next-hop.
When performing a ping from an on-prem server to a VM in a spoke (peered) VNET i see traffic going back and forth over the fortigate (TCPDUMP), so the VPN from on-prem to the HUB VNET works, and from HUB to Spoke, the VM in the Spoke answers and sends the traffic back to the NVA who sends it towards the virtual network gateway and thats where the traffic seems to drop dead cause we do not see it arrive at the on-prem firewall (VPN).