I have a vMX deployed in its own subnet in Azure, the vMX has IP 10.6.250.12/29, the resources in Azure that it needs to access are in 10.6.250.128/25, and VPN connected users are allocated an address in 10.6.249.0/24. The vMX is configured as a concentrator because I can't have it NATing everything out of its single interface as it becomes difficult to isolate captures from individual clients if everything has the same source IP - it also papers over missing routes and this is going to be a very stable setup once it's built. I have created a route table with a single route for my VPN clients, which is to say that 10.6.249.0/24 has a next-hop IP of 10.6.250.12. I assigned this to the subnet with my resources in, I also made sure this subnet was added in the vMX as a local network in the site-to-site VPN settings, and that it was a route that my VPN clients knew about. The VPN connects successfully, but I can't ping anything in 10.6.250.128/25. Running a packet capture on the vMX shows the packets leaving, but nothing coming back. Pinging an address in the VPN subnet from the resources in Azure results in nothing showing up in the packet capture. The only thing that brings everything to life is adding the route table onto the same subnet as the vMX is in - something that the docs explicitly say not to do. Unfortunately I have no hard proof but I am convinced something has changed in Azure here - I deployed a virtual SonicWall a month ago and had to do the same thing (add the route to the same subnet as the firewall interface) where previously I am sure you only needed to tell the subnet where the traffic was originating from what the next-hop address was, rather than needing to 'walk' the packets through the subnet your appliance lives in, it's possible I am skipping a step and forgetting but my deployment is quite simple and looks the same as the instructions. The Azure docs also say that adding the route to the one subnet hosting the resources is enough, and yet I can run a ping and make it either timeout or work depending on whether this route table has also been associated to the vMX subnet. Has anybody seen this?
... View more