Windows Azure Virtual Networks and IKE Versions
Have you heard about Windows Azure Infrastructure Services? If not, then you’re in for a treat! Windows Azure Infrastructure 
Services enable you to put your virtual machines in the cloud. There are a lot of reasons why you might want to do this. Maybe your datacenter is at capacity and you need to stand up new service. No problem! Put those virtual machines in the Windows Azure Infrastructure Services cloud. Maybe you host a public facing service and you want to move the public facing components out of the corporate network and into the cloud. Windows Azure Infrastructure Services can help you with that too.
My team is working on a project called “Hybrid IT Infrastructure Solution for Enterprise IT” and the focus is on what the IT Pro needs to think about before moving services into a IaaS cloud solution like Windows Azure Infrastructure Services. Issues 
around authentication, authorization, account management, security, performance, availability and networking will be covered in a collection of documents.
Of course, in order for us to provide you the information you need, and help you avoid any potential issues, we have to build out a solution using an application that runs on the hybrid IT infrastructure. The document set will include the results of our findings so that you can more efficiently move applications and services into the Azure Infrastructure Services cloud.
In this article, Yuri Diogenes, who is doing the engineering work on this project, shares with you some findings from when he was trying to connect to an Azure Virtual Network that hosts the virtual machines for the public side of our solution. I think you’ll find the discussion interesting and it give you some insight into discovery and troubleshooting for a specific issue in Azure Infrastructure Services. Think of us a “customer zero” where we find things out and help you avoid potential problems! Enjoy! –Tom.
Almost a month ago I wrote this post about an attempt I made to establish a site to site VPN connection between a TMG firewall and a Windows Azure Virtual Network and the conclusion was that you need a public IP address on your edge device in order for the connection to be successful.
Note:
TMG is not supported for the on premises side of the site to site connection to Windows Azure Virtual Networks. Due to some peculiarities of our test environment, we were forced to use TMG for our early testing.
With that learning in mind, I got a valid public IP address and now I’m ready to rock! It should be straightforward now that I have all the steps in mind and know how it works. Using the same lab environment (but now with TMG having a public IP address I faced a different issue. The tunnel between Azure and TMG connected for a couple of seconds (from the Azure Portal perspective) and then it dropped. This was a consistent pattern, so it was not a one-off transient situation.
Using TMG DataPackager with VPN template I gathered the data that I needed to understand what it was going on. When I started to review the IKE Logging this is what I got:
[0]00FC.0638::00/00/0000-00:00:00.000 [user] |Azure_IP|IkeVerifyPacketHeader failed with Windows error 13824(ERROR_IPSEC_IKE_INVALID_HEADER)
[0]00FC.0638::00/00/0000-00:00:00.000 [user] |Azure_IP|IkeVerifyPacketHeader failed with HRESULT 0x80073600(ERROR_IPSEC_IKE_INVALID_HEADER)
[0]00FC.0638::00/00/0000-00:00:00.000 [user] |Azure_IP|IkeVerifyPacketHeader failed with Windows error 13824(ERROR_IPSEC_IKE_INVALID_HEADER)
[0]00FC.0638::00/00/0000-00:00:00.000 [user] |Azure_IP|IkeVerifyPacketHeader failed with HRESULT 0x80073600(ERROR_IPSEC_IKE_INVALID_HEADER)
[0]00FC.0638::00/00/0000-00:00:00.000 [user] |Azure_IP|IkeVerifyPacketHeader failed with Windows error 13824(ERROR_IPSEC_IKE_INVALID_HEADER)
[0]00FC.0638::00/00/0000-00:00:00.000 [user] |Azure_IP|IkeVerifyPacketHeader failed with HRESULT 0x80073600(ERROR_IPSEC_IKE_INVALID_HEADER)
[0]00FC.0638::00/00/0000-00:00:00.000 [user] |Azure_IP|IkeVerifyPacketHeader failed with Windows error 13824(ERROR_IPSEC_IKE_INVALID_HEADER)
[0]00FC.0638::00/00/0000-00:00:00.000 [user] |Azure_IP|IkeVerifyPacketHeader failed with HRESULT 0x80073600(ERROR_IPSEC_IKE_INVALID_HEADER)
[0]00FC.0638::00/00/0000-00:00:00.000 [user] |Azure_IP|IkeVerifyPacketHeader failed with Windows error 13824(ERROR_IPSEC_IKE_INVALID_HEADER)
[0]00FC.0638::00/00/0000-00:00:00.000 [user] |Azure_IP|IkeVerifyPacketHeader failed with HRESULT 0x80073600(ERROR_IPSEC_IKE_INVALID_HEADER)
[0]00FC.0638::00/00/0000-00:00:00.000 [user] |Azure_IP|IkeVerifyPacketHeader failed with Windows error 13824(ERROR_IPSEC_IKE_INVALID_HEADER)
[0]00FC.0638::00/00/0000-00:00:00.000 [user] |Azure_IP|IkeVerifyPacketHeader failed with HRESULT 0x80073600(ERROR_IPSEC_IKE_INVALID_HEADER)
[0]00FC.0638::00/00/0000-00:00:00.000 [user] |Azure_IP|IkeVerifyPacketHeader failed with Windows error 13824(ERROR_IPSEC_IKE_INVALID_HEADER)
[0]00FC.0638::00/00/0000-00:00:00.000 [user] |Azure_IP|IkeVerifyPacketHeader failed with HRESULT 0x80073600(ERROR_IPSEC_IKE_INVALID_HEADER)
[0]00FC.0638::00/00/0000-00:00:00.000 [user] |Azure_IP|IkeVerifyPacketHeader failed with Windows error 13824(ERROR_IPSEC_IKE_INVALID_HEADER)
[0]00FC.0638::00/00/0000-00:00:00.000 [user] |Azure_IP|IkeVerifyPacketHeader failed with HRESULT 0x80073600(ERROR_IPSEC_IKE_INVALID_HEADER)
[0]00FC.0638::00/00/0000-00:00:00.000 [user] |Azure_IP|IkeVerifyPacketHeader failed with Windows error 13824(ERROR_IPSEC_IKE_INVALID_HEADER)
[0]00FC.0638::00/00/0000-00:00:00.000 [user] |Azure_IP|IkeVerifyPacketHeader failed with HRESULT 0x80073600(ERROR_IPSEC_IKE_INVALID_HEADER)
[0]00FC.0480::00/00/0000-00:00:00.000 [ikeext] 0|NULL|IkeRegConfigChangeNotifyCallback invoked
[0]00FC.0480::00/00/0000-00:00:00.000 [ikeext] 0|NULL|Stopping IKE tracing
The “Invalid header” could be something related with the IKE itself, unfortunately researching for this error didn’t help me too much:
Next step: I need to figure out what’s happening on the wire! To do that, I’ll reviewing a network monitor trace for this traffic and found:
A ha! That explains everything. TMG doesn’t work with IKEV2, hence it fails to negotiate the IKEv2 connection with the gateway on the Azure Virtual Network.
But wait a minute, this used to work. What happened? Prior to GA, Windows Azure was using IKEv1. When you are using Windows Azure Gateway you can configure it to use Static Routing or Dynamic Routing (see more info about these definitions here), if you use Dynamic Routing then Azure Gateway for Site to Site will use IKEv2. This document is getting updated to reflect this change that was introduced in GA.
And please remember: TMG is not supported for site to site connectivity on Azure and now that Dynamic Routing require IKEV2, TMG is not an option even for testing purpose.
Yuri Diogenes
Senior Technical Writer
Server and Cloud Division Solutions Team
There you go! That’s the great thing about working on these kind of projects. As customer “zero” we take the role of the person who wants to use these services and try to get them working. As we discover how the service works, we also discover things that you’ll want to know so that you’ll be able to plan, design, implement and operate a hybrid cloud in the best and easiest way possible. Stay tuned for more learnings.
HTH,
Tom
Tom Shinder
tomsh@microsoft.com
Knowledge Engineer, SCD iX Solutions Group
Follow me on Twitter: https://twitter.com/tshinder
Facebook: https://www.facebook.com/tshinder
