Share via

Use Azure custom routes to enable KMS activation with forced tunneling

  • Article

Previously, if customers enabled forced tunneling on their subnets, OS activations prior to Windows Server 2012 R2 would fail as they could not connect to the Azure KMS server from their cloud service VIP.  However, thanks to the newly released Azure custom route feature this is no longer the case.  The custom route feature can be used to route activation traffic to the Azure KMS server via the cloud service public VIP which then enables activations to succeed.

In order to configure this, use the Set-AzureRoute command (this is only doable via Azure PowerShell version 0.9.1 and higher) to add an entry for the prefix 23.102.135.246/32 and specify the next hop type as “Internet”. 

Example:

PS C:\> $r = Get-AzureRouteTable -Name "WUSForcedTunnelRouteTable"
PS C:\> Set-AzureRoute -RouteName "To KMS" -AddressPrefix 23.102.135.246/32 -NextHopType Internet -RouteTable $r

Name : WUSForcedTunnelRouteTable
Location : West US
Label : Routing Table for Forced Tunneling
Routes :
          Name Address Prefix Next hop type Next hop IP address
          ---- -------------- ------------- -------------------
          defaultroute 0.0.0.0/0 VPNGateway
          to kms 23.102.135.246/32 Internet

 

The highlighted entry is the new route added. 

 As you can see in my example VM, the Guest OS activates successfully.

   

We can also create TCP connections to the KMS server:

C:\Users\dave>psping kms.core.windows.net:1688

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
 
TCP connect to 23.102.135.246:1688:
5 iterations (warmup 1) connecting test:
Connecting to 23.102.135.246:1688 (warmup): 39.32ms
Connecting to 23.102.135.246:1688: 35.94ms
Connecting to 23.102.135.246:1688: 36.21ms
Connecting to 23.102.135.246:1688: 36.23ms
Connecting to 23.102.135.246:1688: 38.57ms
 
TCP connect statistics for 23.102.135.246:1688:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 35.94ms, Maximum = 38.57ms, Average = 36.74ms 

As expected, attempting to connect to other Internet resources fails due to forced tunneling (or may go out via an on-prem gateway):

C:\Users\dave>psping www.msn.com:80
PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
 
TCP connect to 204.79.197.203:80:
5 iterations (warmup 1) connecting test:
Connecting to 204.79.197.203:80 (warmup): This operation returned because the timeout period expired.
Connecting to 204.79.197.203:80: This operation returned because the timeout period expired.
Connecting to 204.79.197.203:80: This operation returned because the timeout period expired.
Connecting to 204.79.197.203:80: This operation returned because the timeout period expired.
Connecting to 204.79.197.203:80: This operation returned because the timeout period expired.
 
TCP connect statistics for 204.79.197.203:80:
  Sent = 4, Received = 0, Lost = 4 (100% loss),
  Minimum = 0.00ms, Maximum = 0.00ms, Average = 0.00ms

Comments

  • Anonymous
    May 20, 2015
    Previously, if customers enabled forced tunneling on their subnets, OS activations prior to Windows Server