Windows Azure Virtual Network VPN with TMG 2010

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 10.4.3.4. 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 192.168.0.1

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 10.4.0.0 to 10.4.255.255
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.