0

We are trying to establish a connection from Azure VNET(10.10.0.0/16) over S2S VPN Tunnel (VpnGw1) to on-premise network (192.168.1.0/24) and then out through sonic wall to second VPN Tunnel to separate subnet (166.x.0.0/16). We can't seem to get the custom routing to route the traffic correctly.

The topology is below. Our firewall at 192.168.1.1 handles the network routing from 192.168.1.0/24 to 166.x.0.0/16 by routing to the sonic wall at 192.168.1.5. We have a routing table defined for the subnet , setup for 166.x.0.0/16 to use the next hop (virtual appliance) of 192.168.1.5 (we have also tried the next hop as 192.168.1.1).

Network Topology

We can ping successfully both 192.168.1.1 and 192.168.1.5 from 10.10.0.6 (the VNET default routing is handling this fine).

We can make a successful ping from 192.168.1.30 to 166.x.y.z (the routing in the on-premise network is working).

We can't ping 166.x.y.z from 10.10.0.6 and we can't figure out the routing configuration in Azure to enable this. Packets don't seem to be reaching the SonicWall at 192.168.1.5.

Is there something we are missing here? Have we got the configuration wrong in the route table? Does Azure need something else for this route to work?

Edit 1

We tried adding a user defined route of virtual network gateway for the 166 subnet, with no luck. Effective route shows below:

Effective Route

No IP is showing in this user defined route. Not sure if there is some limitation of Azure here?

#Edit 2

I've clarified the subnet mask is 166.x.0.0/16 , updated the diagram. To confirm: From 10.10.0.0/16 pings to 192.168.1.0/24 From 192.168.1.0/24 pings to 10.10.0.0/16 From 192.168.1.0/24 pings to 166.x.0.0/16 From 10.10.0.0/16 does not ping to 166.x.0.0/16 Packet capture on 192.168.1.0/24 router confirms ICMP packets are not reaching the router from pinging to 166.x.0.0/16 from 10.10.0.0/16.

5
  • 1
    Please paste your image into the question instead of a link.
    – Ron Trunk
    Apr 24, 2023 at 12:05
  • @RonTrunk I have changed the image to be embedded rather than use the default behaviour. Seems harder to read the image as it's now not possible click and view it full size? As I'm new to this stack I'll do as I'm asked.
    – Jayden
    Apr 24, 2023 at 19:48
  • 1
    Right click, Open image in New Tab worked fine for me :)
    – Mintra
    Apr 24, 2023 at 20:39
  • Please clarify: "From 10.10.0.0/16 does not ping to 166.x.0.0/16 Packet capture on 192.168.1.0/24 router confirms ICMP packets are not reaching the router from pinging to 166.x.0.0/16 from 10.10.0.0/16." - which direction's ping does not appear in capture on which router?
    – Mintra
    Apr 30, 2023 at 20:34
  • Hi @Mintra, yes ping from 10.10.0.0/16 to 166.x.0.0/16, we can't see the ICMP packets reaching 192.168.1.1 (capturing packets on 192.168.1.1)
    – Jayden
    May 8, 2023 at 0:48

1 Answer 1

1

Likely the subnets in Azure do not have any routes to reach 166.x.y.z. You need to do one or other of these:

  • Configure BGP between one of your on-prem routers and the Azure VpnGw to advertise that prefix to Azure. This is the proper, more scalable appoach, but only good if your router/firewalls support it and you are familiar with the basics of eBGP.
  • Alternatively, ceate and attach a User Defined Routing table in the back-end-subnet that statically routes 166.x.y.z to a Virtual network gateway type next hop.
6
  • Mintra - we tried adding a Virtual Network Gateway type next hop as a User Defined Route - still no luck (I've added a screenshot to the question edit).
    – Jayden
    Apr 25, 2023 at 20:51
  • Have you also checked the reverse direction: that whatever router is responsible for 166.x.0.0/16 over on the right of your diagram knows about the 10.10.0.0/16 network in Azure? By the way, can you be consistent or clarify on the mask lengths for the 166 network - the inconsistency (24 vs 16) coupled with the obfuscation is confusing!
    – Mintra
    Apr 26, 2023 at 9:13
  • Thanks Mintra - I've fixed the masks to be consistent and correct. Yes, we can ping from 192.168.1.0/24 subnet back to Azure 10.10.0.0/24 subnet fine. We are continuing to try and work on it and figure it out.
    – Jayden
    Apr 28, 2023 at 8:25
  • Just to clarify: so 192.168.1.1 terminates the VPN to Azure, 192.168.1.5 terminates the VPN to 166.x.y.z? What kind of the VPN is the latter - if it's policy based (rather than route based) do you have phase 2 policies for 166.x.y.z/16----10.10.0.0/16 configured?
    – Mintra
    Apr 30, 2023 at 20:35
  • Yes @Mintra, correct. Unfortunately the device at 192.168.1.5 is a managed device which we don't have access to. They assure me it is configured to allow for the routing Azure and the second VPN. We can't see packets arriving on our 192.168.1.1 from Azure when we attempt a ping to 166.x.y.z so we assume that there is an issue at Azure or 192.168.1.1. I'll mark the answer you've given correct as I think you are right, and we will go down a different avenue to try and resolve.
    – Jayden
    May 8, 2023 at 0:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.