Compartilhar via

Use Azure custom routes to enable KMS activation with forced tunneling

  • Artigo

If customers enable forced tunneling on their subnets to force internet connectivity via on premises equipment, OS activations prior to Windows Server 2012 R2 fail as it does 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”.

Note: in the directions below, the IP 23.102.135.246 referenced is for the Azure public cloud regions and corresponds to the DNS name kms.core.windows.net.  For national clouds, look up the relevant IP for the DNS name that corresponds to the appropriate cloud and use that IP instead.  DNS names by national cloud:

  • Azure public cloud regions: kms.core.windows.net
  • Azure China national cloud regions: kms.core.chinacloudapi.cn
  • Azure Germany national cloud regions: kms.core.cloudapi.de
  • Azure US Government national cloud regions: kms.core.usgovcloudapi.net

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