I am trying to setup a site-to-site-vpn with an azure-virtual-network and an azure-virtual-machine to a local-network and a local-computer.
The VPN-Gateway has managed to establish a connection to the VPN-Device, but does not let traffic travel between the networks. It is probably it is caused by a configuration error somewhere.
Is there any tools I can use that can pin-point the problem?
I have tried downloading the AzureVNetGatewayDiagnostics but I dont see any problems with it. Anything else I can try?
Did you follow the instructions here https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-create-site-to-site-rm-powershell/ when you set up the S2S VPN?
When you open the connection in the Azure portal, is there any traffic registered? There should read how much data has been sent and received through the connection. The status should also read "Connected". The connection in question is the one created in step 8.
Also, in the "local network gateway" in the Azure portal, are the correct subnets defined for your on-premise networks? I.e. in the configuration section, in the portal, for the gateway should read something like 192.168.0.0/24. This is created in step 3.
Note: if you change these settings after creating the gateway in Azure, you must recreate the connection object. See the "To modify IP address prefixes for a local network gateway" section for more information.
In the same way, check that the remote subnets are also defined in your local device. There should read something like 10.0.0.0/16 if that's the subnet you used for the remote subnet you are trying to connect to.
If all that's fine, then also check that your local firewall is configured to route traffic to through the right interface.
Finally try to run e.g. tracert <remote vm ip>
and see what it returns. If all is fine it should look like
C:\>tracert 10.0.1.15
Tracing route to 10.0.1.15 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.0.1
2 * * * Request timed out.
3 47 ms 48 ms 51 ms 10.0.1.15
Trace complete.
If you run the same from a remote VM against a local IP it should return a similar result.