ADFS on Azure Virtual Machines (part 1)

Microsoft's Windows Azure Virtual Machine (IaaS) and Virtual Network offerings provide some incredible opportunities for a remote datacenter that you can spin up quickly and without breaking the bank. I needed an ADFS environment for an SMB client who was moving to Office 365, wanted to use SSO, but did not want to have to rely on the on-premises environment to be able to access Office 365. I decided to handle all of their ADFS authentication needs using Azure IaaS. (Links to other articles in the series are in the conclusion.)

UPDATE: I had an Azure billing issue that forced me to suspend the writing of this blog series for awhile. In the meantime, a new version of DirSync has been released that does password (hash) syncronization. While following this series will still help you get ADFS up and running on Azure, ADFS may not be the best solution for your SMB any longer.

Azure Virtual Networks and Netgear VPN (or other unsupported VPN)

Virtual Network Introduction and Requirements

Azure Virtual Networks allow you to enable the virtual machines you have on their IaaS offering to communicate privately with each other as if they were all connected to the same LAN. Further, you can connect the Virtual Network to your on-premises LAN via a VPN connection to enable your on-premises endpoints to communicate with the Azure Virtual Machines.

You will need:

  • Private network subnet (Address Space in Azure parlance) that can be further subnetted and does not collide with your on-premises network or any other network you route to from your on-premises network
  • Router capable of a site-to-site IPSec VPN (The supported router list is rather small. Most of the routers are pretty expensive, though a few are affordable for smaller shops. More importantly, who wants to rip the heart out of the production network to use this solution? I'll show you some workarounds to do this with the gear you already have. My example is a Netgear Prosafe router.)
  • Azure subscription (Free trial works great. The guide makes the assumption that you are starting from scratch with an empty subscription. If you already have solutions deployed to your subscription, hopefully you've picked up the necessary experience with Azure to modify the guide as needed.)
  • On-premises DNS Server for Azure Virtual Machines to use

Create a Virtual Network

Let's get started by creating the virtual network. You will need to login to the management portal for your Azure subscription. Be careful as you follow these steps. A lot of these settings cannot be altered without deleting the entire virtual network (which, in and of itself, can be challenging), so... don't bonk!

  1. Click New (bottom-left) > Networks > Virtual Network > Custom Create.
  2. Name your virtual network (this is just a friendly name for you to see in the management tools), select "create a new affinity group," and choose the appropriate region and affinity group name (again, a friendly name for administrative purposes), then click the next arrow in the bottom right.
  3. Enter the name (just a friendly name, but I'd recommend using the machine name to avoid confusion) and IP address of an on-premises DNS server for use by your Azure Virtual Machines, check the "Configure Site-to-Site VPN" checkbox, and click the next arrow.
  4. Choose a friendly name for the local network, enter the public IP address (the one you want the VPN to terminate on) of your router, and choose an address space. (This address space is the subnet of your on-premises network that the Azure VPN will route to.) Click the next arrow. (The VPN Device IP Address in the screenshot is bogus, but you should use your router's IP, not one of the IP's. :-) )
  5. Choose an Address Space that does not collide with any of your existing networks. (The address space is the subnet that your router will actually route to over the VPN, but it will include the gateway subnet and at least one subnet where you can place virtual machines as well.) Define at least one subnet for virtual machines within that address space, and define a gateway subnet, then click the finish checkmark.
  6. You will be taken to the Virtual Networks screen. Click to select the network you just created, then click Dashboard. Click Create Gateway > Static Routing and confirm the creation. Now would be a good time to tell whoever is in charge of your firewall that he may see some attempts to create a VPN tunnel start coming in! Grab the subscription ID, local network name, and Virtual Network name while you are on this screen, because we will need them in a moment.

Windows Azure Virtual Network configuration for Netgear VPN

These steps are for Netgear's Prosafe VPN routers, but there is helpful information here for anyone attempting to use a router that is not on the "approved" list. The primary hurdle to using a Netgear router (or many other prosumer routers) for an Azure VPN is the PSK length. You see, the default PSK length for the Azure VPN is 50 characters (see update below), and the maximum PSK length for many routers is... you guessed it 49 characters. The PSK length can be changed, but the process is unfortunately not for the faint of heart. Lucky for you, I've done the heavy lifting for you and have created a C# Console app that will change the settings for you. If you'd rather not trust my app, you can follow the original outline of my manual procedure here.

UPDATE: The Azure team has changed the default PSK length to 32 characters, so steps 2 and 3 below are no longer needed unless 32 characters is not workable PSK length for you.

  1. Install Windows Azure PowerShell (we will need it for some later steps as well) using these instructions
  2. Download my app that will generate the shorter PSK for you.
  3. Run the app and provide it with the requested information from Azure PowerShell.
  4. Back in the Azure Management Portal, click the "Manage Key" button to collect your 49 character PSK. Go ahead and collect the Gateway IP Address because we'll need that shortly as well.

Netgear VPN Configuration for Windows Azure Virtual Network

I will be using a SRX5308, but the VPN stack is the same on every Netgear Prosafe router I've ever seen, so you should be able to follow these instructions with any model. If you're using a router other than Netgear, it may be helpful to determine which underlying VPN solution your router uses. For instance, Netgear routers use the Racoon VPN implementation. I had better luck finding documentation on Racoon itself and Azure than I did on Netgear and Azure. Then again, that was before this guide was written! ;-)

  1. We will use the Netgear VPN Wizard (in the Netgear web management interface of the router) to setup a VPN connection, which we will then tweak for interoperability with Azure Virtual Networks
    • VPN > IPSec VPN > VPN Wizard
    • Choose Gateway as the VPN type
    • Enter a friendly Connection Name, the 49 character PSK, the remote WAN IP Address (Azure Gateway IP Address), and Remote LAN IP and Subnet (remember that these are the Azure Virtual Network Address Space values, not the Azure subnet or gateway subnet)
    • Select the appropriate WAN port (if your router has multiple WAN ports), and the Local WAN IP address shoudl be populated. If it is not, or if a hostname is populated, replace with the VPN Device IP Address you specified in Azure when you created the Local Network. These values must match.
    • Click Apply
  2. Edit the VPN Policy (Phase II)
    • VPN > IPSec VPN > VPN Policies
    • Check the box next to your VPN Policy and click Disable
    • Click Edit to edit your VPN Policy
    • Under "Auto Policy Parameters" the default values for SA Lifetime (3600 seconds) and Integrity Algorithm (SHA-1) can remain. Change Encryption Algorithm to AES-128 and uncheck PFS Key Group (this will disable PFS for Phase II, but we will still use it for Phase I).
    • Click Apply
  3. Edit the IKE Policy (Phase I)
    • VPN > IPSec VPN > IKE Policies
    • Click Edit to edit your IKE Policy
    • Under IKE SA Parameters the default values for Authentication Algorithm (SHA-1), DH Group (Group 2 1024 Bit), and SA Lifetime (28800 sec) can remain. Change Encryption Algorithm to AES-128.
    • Click Apply
  4. Re-enable the VPN Policy (VPN > IPSec VPN > VPN Policies, check the box, click Enable.
  5. Check for "IPSec SA Established" on VPN > Connection Status. If present, your VPN connection from your Netgear router to your Azure Virtual Network has been established.


Please check back to see the next articles in the series for information about deploying and load-balancing virtual machines, AD, ADFS, and ADFS Proxy in Windows Azure. This will be covered in future articles, but if you're not planning to come back for those, make sure to lower the MTU on your Azure virtual machines from the default 1500 to 1350 (or another value you test in your network), or packet fragmentation over this VPN will make the performance terrible. Thanks for reading, and have fun! Here's a quick review of where we've been and where we're going.



The download link for your app doesn't seem valid anymore.

Comment by David on May 15, 2013 at 3:49 pm

Sorry about that, David! The URL for the app had a typo in it. It should be all set, now. Thanks for pointing that out, and thanks for reading! Give me a shout if anything else comes up, and I'll be happy to help!

Comment by Joe Sutherland on May 15, 2013 at 3:57 pm

Do you know why i can create a connection but cant ping anything in either network? i am using a SRX5308 router.

Comment by BBB on June 5, 2013 at 10:22 am

Any chance you could create a version that would change it to a key that is less than 25 characters? I really need it as I haven't had any luck running the commands on my own. I'd be happy to pay for your time to create it.

(sorry if this is a double post)

Comment by Aaron on February 12, 2014 at 11:26 am

Links to part 4,5 and 6 seem to be broken. they don't work. Please make them available.

Comment by Pierre on August 28, 2014 at 9:40 am

@BBB Azure IAAS hosts (VMs, routers, etc) do not respond to pings, so that's not a good troubleshooting step for you, unfortunately.

@Aaron I'm sorry for the long delay. If you still need this, I'd be happy to do it for you, but you'd have to reach out to me with some contact information.

@Pierre I got busy and never finished the series. :-/ Much has changed in Azure since I wrote this, and many of the pain points I worked around have been smoothed out by Microsoft. I need to revisit this series with current Azure capabilities in view. Hopefully soon!

Comment by Joe Sutherland on August 28, 2014 at 10:41 am



Exact Technical Solutions LLC
2435 E. North Street, #118
Greenville, SC  29615
phone: 864.292.9391