0

I have a rather (relatively) tricky situation:

I have to get a VPN tunnel up, between my virtual machines on an Azure subnet and servers behind a telco's VPN gateway. I chose to use the in-built VPN capabilities of Azure, and so started configuring a Site-to-Site VPN connection via the management portal.

My partner did share with me the public IP of their gateway, and the IPs of the peers on their subnet with which I'll interact. With this info, I did setup a local network, which I then specified as the one to connect to when I configured my own VPN subnet on Azure (subnet, and gateway now up and running).

My partner did indicate that they were using a Cisco ASA 5520 device (which, though not in the drop down for supported devices on Azure's VPN Device config generator, I believe is close to the supported version - ASA 55000 series). I then obtained the VPN device config generated by Azure, and shared it with my partner. The most critical thing being that we had to ensure our IPSec and IKE encryption parameters matched (esp-aes-256 esp-sha-hmac).

But, despite me confirming that my gateway is up (using nmap's stealth scans, since Ping can't work on Azure), and proving that the partner's gateway IP is also up, I don't know why I the VPN isn't coming up!

What else do I need to cross-check? What should I ask my partner (who has a solid networking team, and is convinced the issue is on my side) to check against?

BIGGEST ISSUE: Azure's VPN endpoint is a blackbox - besides being able to configire and tweak the VPN gateway, DNS and subnets, all the other critical things - IPSec and IKE, etc are only dictated, with me, the user not being able to modify these parameters. So, how does one go about troubleshooting their side (Azure) of the VPN?

NOTE: I already ensured that we have the same PSK as well.

2
  • Simply you can't. However by providing the telco with the config and the logging available on the asa5520 they should be able to establish what the problem is. I recently configured a vyatta vpn server to work with azure and I only had the logs on my side which were enough to establish I'd configured perfect forward secret wrongly for example. – Drifter104 Jul 28 '15 at 13:16
  • @Drifter104 thanks. Indeed, this is might be the case. I also had configured Static Routing on the Azure side, but my peer was using PFS on his Cisco device. I've since told him to disable that. Now, waiting to see if tunnel comes up... (it's still just trying to connect.) – nemesisfixx Jul 28 '15 at 14:13
1

You can use the Powershell cmdlet Get-AzureVirtualNetworkGatewayDiagnostics to dump gateway logs (from the azure side obviously) to an azure storage account and download them from there. We've used it in the past to troubleshoot at least basic problems.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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