Microsoft announced Windows Azure Virtual Network and Windows Azure Virtual Machines in June 2012 to provide IaaS ‘Hybrid Cloud’ functionality.

What this allows is persistent Virtual Machines (which retain the same private addresses) running in Azure that can be joined to your on-premise Active Directory using a site-to-site IPsec VPN. The Azure VMs then act like a branch network with full connectivity and you can add Domain Controllers in the Azure Virtual Network.

This is still a preview release and Microsoft currently only support specific Cisco and Juniper devices that have been tested. The VPN Devices for Virtual Network page explains that other devices may work as long as they support the following:

  • VPN device must have a public facing IPv4 address
  • VPN device must support IKEv1
  • Establish IPsec Security Associations in Tunnel mode
  • VPN device must support NAT-T
  • VPN device must support AES 128-bit encryption function, SHA-1 hashing function, and Diffie-Hellman Perfect Forward Secrecy in “Group 2” mode
  • VPN device must fragment packets before encapsulating with the VPN headers

TMG 2010 does support these requirements but getting full connectivity working has proven to be harder than expected. Hopefully this post will save others a lot of time.

Create Azure Virtual Network and Start Gateway

The first step is to create the Azure Virtual Network and Microsoft have a good tutorial explaining it here.

If you will be deploying Active Directory into your Virtual Network, you cannot use Azure DNS and will need to provide details for your AD DNS. More information is available here.

The first VM deployed to each subnet will get the .4 address for example For the DNS question (step 6 in the tutorial) enter the .4 address for your subnet and also add an on-premise DNS server for example

It is important to note that once you have created the Virtual Network and deployed a Virtual Machine the configuration cannot be modified, other than adding subnets. Hopefully this is something that will be available once these services are out of beta.

Starting the gateway can take a long time. I haven’t seen any documentation on how it works, but I suspect it is spinning up a VM in the background to act as the Azure VPN endpoint. Once the gateway is created, take note the IP address and Shared Key and we can move on to the TMG configuration.

Create TMG IPsec site-to-site VPN

During the setup of the TMG VPN I had a few times where I thought I had it working only to hit another stumbling block. The summary of the things I needed to change are:

  1. Setup TMG IPsec with a supported configuration
  2. Modify TMG network rule and access rule
  3. Make sure the TMG server has hotfix KB2523881 installed
  4. Change the TMG network card MTU to 1350
  5. Disable RPC strict compliance and restart TMG firewall service

IPsec Configuration

I used the content of this massive MSDN forum post to create the IPsec site-to-site VPN and get traffic flowing with the TMG configuration information coming from David Cervigon.

  1. Remote Access Policy (VPN) / Remote Sites / Create VPN Site-to-Site Connection
  2. Choose ‘IP Security protocol (IPsec) tunnel mode
  3. Remote VPN gateway IP address: enter the Azure Virtual Network gateway provided earlier
  4. Local VPN gateway IP address: enter the TMG external IP address
  5. Use pre-shared key for authentication: Enter Shared Key provided earlier
  6. Remote address ranges: Leave the Azure IP address and enter the Azure network range created earlier for example to
  7. Network rule: Create a route relationship and add other networks if required
  8. Access rule: Create an access rule and select ‘All outbound traffic’
  9. Address ranges: Leave the external interface and add the internal network ranges that need to communicate over the VPN
  10. Create the VPN and edit
  11. Under Connection / IPsec Settings ensure the following is set:
    1. Phase I
      1. Encryption algorithm: AES128
      2. Integrity algorithm: SHA1
      3. Diffie-Hellman group: Group 2 (1024 bit)
      4. Authenticate and generate a new key: 28800 seconds
    2. Phase II
      1. Encryption algorithm: AES128
      2. Integrity algorithm: SHA1
      3. Session key / Generate a new key every: Both enabled
      4. Kbytes: 102400000
      5. Seconds: 3600
      6. Use Perfect Forward Secrecy (PFS): Not selected
      7. Diffie-Hellman group: N/A

Below is the TMG IPsec configuration.

TMG Network and Access Rules

The automatically created Network Rule and Access Rule allow only one way initiated traffic.

  1. Modify the Network rule under Networking / Network Rules and add ‘Internal’ to the source network and ‘Azure’ to the destination network
  2. Modify the Access rule under Firewall Policy and add ‘Internal’ to the source network and ‘Azure’ to the destination network

Below is the TMG configuration.

TMG Server Hotfix KB2523881

At this point I could see the VPN connect:

However no traffic was flowing. I was running TMG 2010 SP 1 Software Update 1 and after installing hotfix KB2523881 the VPN worked. I tried to install the hotfix on another TMG server with SP 2 and all Windows Updates and it said it was not needed. This may be included in TMG 2010 SP 2 or as part of another update from Windows Update. (Update 26 July: tcpip.sys and fwpkclnt.sys are updated by Windows hotfix KB2582281 and MS12-032 KB2688338 )

TMG Network Card MTU

At this point I could add my first virtual machine, join it to the domain but could not get AD to replicate from on-premise to Azure. The issue was the MTU on the external network card on TMG which was mentioned somewhere in the MSDN forum above. The MTU needs to be set to 1350 to account for the IPsec overhead and the default is 1500.

  1. Open an administrative command prompt
  2. Run to show interfaces
    1. netsh interface ipv4 show interface
  3. Set external interface MTU
    1. netsh interface ipv4 set interface “EXT” MTU=1350

Below is a screenshot of the change.


Disable RPC Strict Compliance and Restart TMG Firewall Service

Almost there. The issue I faced now was that my Virtual Machine Domain Controller could not use any DCOM RPC services like certificate self-enrolment and opening the Certificate Authority MMC. TMG blocks all non endpoint mapper RPC traffic like DCOM – more information is available here. I tried disabling RPC strict compliance, changing the DCOM port and creating a custom rule as shown here but it did not work. I eventually tried to disable the RPC filter completely in System / Application Filters which, although drastic, did work. The reason it worked is because it forces a restart of the TMG Firewall service which it turns out is all that was needed to apply the previous configuration changes. I re-enabled the RPC filter and set the DCOM back to standard ports and from my testing the following is needed:

  1. Right click the Access rule, select ‘Configure RPC protocol’ and uncheck ‘Enforce strict RPC compliance’
  2. Edit the System policy ‘Firewall Policy / All Tasks / System Policy / Edit System Policy / Authentication Services / Active Directory’ and uncheck ‘Enforce strict RPC compliance’
  3. Apply the TMG configuration and wait for it to sync
  4. Important:The next step will disconnect all TMG sessions including VPN, RDP, ActiveSync, OWA etc. so should be performed out of hours
    1. Restart the ‘Microsoft Forefront TMG Firewall service

It Works!

That should be all that is needed. Not particularly hard but getting all the information and testing took a long time. I hope that this helps somebody and prevents a lot of wasted time.

The next blog will cover PowerShell provisioning the first Domain Controller in Azure so that it can join the on-premise domain and adding other domain joined machines.

Azure Infrastructure

Join the conversation! 25 Comments

  1. Thanks for this summary Marc. It really helps.

  2. Hi Marc, may I know your TMG whether it was facing public or behind NAT?


  3. My TMG public interface had a public IP address assigned directly, so no NAT. The VPN requirements page says that the VPN server must have a public facing IPv4 address (implying no NAT) and the cross-premises VPN page says ‘This VPN device cannot be behind a NAT’.


  4. Hi,

    Ever heard of a way to make it work behind a NAT ?
    All my config is OK, i’m “connected” in Azure Virtual Network, but all traffic is only INBOUND, no OUTBOUND.
    ping between cloud network and local network do not work…

    And indeed, my TMG is behind a NAT (no public facing IP, but DMZ host is pointing on TMG on the ISP box)

    To be “connected” in azure virtual network, I must put my -not public- TMG external IP on the local endpoint in the configuration.

    Just frustrating !

  5. Pilow – Not with Azure VPN. I have used TMG site to site VPN behind a NAT, but if you look at my comment above yours, the Azure VPN page is very specific about NAT.

  6. Yeah, I was aware of that… no NAT. Was just hoping that had changed since October 18 🙁

  7. i have followed the same procedure and cannot ping both internal lan servers, i have a public ip in my tmg 2010 and i successfully established the VPN Gateway with Windows Azure

    • Make sure you have a static route on the internal servers to direct traffic to the TMG server internal IP address. Also ensure you have the patches for TMG installed.

  8. I have setup this before and am trying to do that with a new Azure subscription now but it never connects on the Azure site. I can see the connection on TMG but it seems Azure never sees it. Any ideas?

  9. This worked great. I have one issue though, I can’t seem to get 80/HTTP traffic from the internal to Azure to work. Everything else is fine even SSL. I have a feeling this is due to the web proxy that TMG has, but I can’t seem to bypass it no matter what I try. This isn’t the main internet router for my test network, but just a leg I have setup. Any thoughts?

    • Shawn, any luck with this? I’m having the same problem. Can RDP (etc) to an Azure VM, but can’t get HTTP to work.

      • Finally figured it out. TMG’s HTTP protocol definition is associated with the Web Proxy filter, which effectively makes the traffic to Azure seem to come from the TMG server itself, and not get routed via the IPSec tunnel.

        I created an “HTTP No Web Proxy” protocol for outbound TCP 80 traffic, and did not associate it with the Web Proxy filter. Then added a firewall rule above the “all traffic” rule for the site-to-site VPN to allow the “HTTP No Web Proxy” traffic to between my Internal and Azure network definitions.

        That should have been it, but it didn’t seem to work until I also edited the “all traffic” rule to “All outbound traffic except selected” to specifically exclued the original HTTP (with web proxy filter) protocol definition.

  10. I don’t have my Azure VPN setup any more, but if you have a route on the internal computer going to TMG then it should work and the web proxy should not impact it. TMG logs should be able to tell you more, but you can disable the web proxy under ‘Web Access Policy’ if required.

  11. Marc, can AZure allow to connect the VM running in AZUre from external world using a url.
    Example: looking to place ADFS 2.0 in Azure and perform netting url – point to the ADFS 2.0 server on port 443.

    Any info will be of great help.

    • That is possible. All VMs have a public IP address and you can choose the endpoints that get published. ADFS and ADFS Proxy in Azure works well

  12. Marc, I am stuck wherein my ADFS server running on Azure has a ip address with 443 port open. But while accessing the server using the External IP address from a browser doesnt lands to the IIS default webpage.

    I am trying to enable ADFS,but seems I am missing some basics.
    Please help.


    • To test ADFS go to ADFS 2012 R2 (and Web Application Proxy) are not IIS based and so do not have a default web page. If the port is configured as an endpoint and the services are started, then check the local firewall. And make sure you haven’t applied ACLs on the VM. Another thing to check is that you have a valid certificate for the ADFS FQDN, that your client trusts the certificate and that you have DNS or a hosts file configured to connect on the correct FQDN.

Comments are closed.