Enable the forwarding function on Windows Server Gateway: a use case study

Windows Server Gateway in Windows Server 2012 R2 is a key element of Hybrid Networking, which enables enterprises to connect to service providers via site-to-site VPN. This blog describes a different use case. It shows how Windows Server gateway can be configured to forward traffic between a traditional VLAN network and a virtual network (or “VM Network” in System Center Virtual Machine Manager), which is enabled by Hyper-V Network Virtualization.


Hyper-V Network Virtualization virtualizes the physical network so that each virtual network created on top of the physical network has the illusion that it runs on a dedicated network. Network Virtualization using Generic Routing Encapsulation is used to encapsulate packets, hereby separating the Customer Address & routing from the Provider Address & routing. Because of encapsulation, packets to and from a virtualized network must go through a gateway. We implemented this gateway in Windows Server 2012 R2. So if you want to connect to a remote site you can enable the site-to-site VPN function on the gateway. If you want to connect to the Internet you can enable the NAT function on the gateway. Are there any other scenarios where you can use the gateway? Sure you can. Consider the following:

  1. You are an enterprise and have a private cloud. You plan to virtualize the physical network gradually for your tenants, e.g. business units. In the process, you want to make sure there’s connectivity between tenants that are already virtualized and those that aren’t;
  2. You are a service provider and have a public cloud. Some of your tenants connect to you through MPLS. You want to connect the tenants to their virtual network.

Both the scenarios require you enable what we call the “forwarding” function on our gateway. Simply put, the gateway will serve as a router to forward traffic between networks – virtualized or not. We’ll walk you through the second scenario and describe how you can do it in this blog.

Connect remote site to virtual network through an existing edge

To expand the second scenario, let’s say an enterprise employs a service provider for additional server capacity. The enterprise has an on-premise network and an HNV based virtual network located in the service provider’s datacenter. The enterprise contracts a telecom which connects the enterprise to the service provider via MPLS. The service provider then deploys the Windows Server gateway to connect the enterprise’s virtual network to the enterprise’s on-premise network.


Here’s a high-level overview of the packet flow, from this enterprise’s on-premise network to its virtual network.

  1. Packets enter the MPLS cloud from the enterprise side;
  2. Packets exit the MPLS cloud and enter the service provider’s datacenter;
  3. The edge device delivers the packets to a multilayer switch. Because the enterprise’s packets are not routable in the service provider’s network, the service provider needs to “tunnel” the packets. If the “Core” network is layer 3, it may use GRE or IP-in-IP tunneling. If the “Core” network is layer 2, it may use Q-in-Q VLAN. There may be other mechanisms to achieve the same goal.
  4. The “downlink” of the multilayer switch is usually configured with VLAN. So the packets will be VLAN-tagged on the wire between the switch and the Windows Server gateway.
  5. The Windows Server gateway maps VLAN to the associated tenant network (identified by a Virtual Subnet ID or VSID), and routes the packets to the final destination on the virtual network.

Now if you use our inbox site-to-site VPN solution, encrypted packets from the enterprise’s on-premise network, which are sent over the Internet, will come all the way to the Windows Server gateway where they’re decrypted. Many people like to call it “site-to-site VPN tunnel termination”.

Network Configurations

In order to explain the nuts and bolts of how this scenario works, we’ll go over the configurations manually using PowerShell. For normal deployments, you should use System Center Virtual Machine Manager.

Assume the virtual network is already configured. The next three steps are required to establish connectivity between the two networks via Windows Server Gateway.

  1. Hyper-V host configuration
  2. Gateway configuration
  3. On-prem router configuration


Hyper-V host configuration

This machine hosts the gateway. The gateway must have at least two VM NICs, one facing the external network, i.e. the enterprise’s on-premise network, and one facing the internal network, i.e. the enterprise’s virtual network. Typically, an admin needs additional NICs for management or clustering. But this document focuses only on the “external” NIC and the “internal” NIC configuration.

External NIC

Set VLAN on the “external” NIC.

Set-VMNetworkAdapterVlan –VMName “ForwardingGW” –Name “External” –Access –VlanId 5

It should be noted that if, in your network, traffic between the multilayer switch and the gateway is not VLAN tagged, you don’t need this configuration because by default Hyper-V switch doesn’t tag traffic to and from a VM.

Internal NIC

Enable HNV for the “internal” NIC.

Set-VmNetworkAdapterIsolation -VMName “ForwardingGW” -VMNetworkAdapterName "Internal"
 -IsolationMode NativeVirtualSubnet -MultiTenantStack Off

The isolation mode is Hyper-V Network Virtualization (“NativeVirtualSubnet”). We’ll discuss other possible configurations in the future. This configuration is a prerequisite of running the following cmdlet.

Add-VmNetworkAdapterRoutingDomainMapping -VMName “ForwardingGW” -VMNetworkAdapterName
 "Internal" -RoutingDomainID "{00000000-0000-0000-0000-000000000000}" -RoutingDomainName "default"
 -IsolationID 6000 -IsolationName "Enterprise1”

"{00000000-0000-0000-0000-000000000000}" is a special routing domain ID. When specified, the Hyper-V switch and the gateway will “connect” the tenant virtual network to the external network in the default compartment.

6000 is a special virtual subnet designated to connecting a virtual network to the virtual network’s gateway.

Gateway configuration

This is the gateway running in a VM hosted on the Hyper-V host described earlier.

First, find the two IP interfaces, on which we’ll configure IP addresses and routes later. Run “Get-NetIPInterface -AddressFamily IPv4”.

You’ll see an interface named as “Enterprise1”. The name of the interface comes from the configuration on the Hyper-V host (see “Add-VMNetworkAdapterRoutingDomainMapping” above). It is bound to the “Internal” NIC. Assume “Ethernet” is the IP interface bound to the “external” NIC.

Next, set the IP address on the two IP interfaces

New-NetIPAddress -InterfaceAlias "Enterprise1" IPAddress -PrefixLength 24 is the gateway IP address for this enterprise’s virtual network.

New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress -PrefixLength 24 is the address that this enterprise must tell the service provider to configure on the gateway. This address must be routable in the enterprise’s network. In the other words, this enterprise must be able to ping this address from its on-premise network.

Next, set up the routing table.

New-NetRoute -InterfaceAlias "Enterprise1" -DestinationPrefix

This route says any packets destined for, i.e. the virtual network, should be sent to, which is the “so-called” default gateway for the virtual subnet Refer to the above configuration, where the gateway IP is on

New-NetRoute -InterfaceAlias "Ethernet" -DestinationPrefix -NextHop

This route says any other packets should be sent to the on-premise network. is the default gateway. It is configured on a router in the on-premise network. In most cases, it needs to be statically configured. In other words, along with, the enterprise must tell the service provider about this IP address.

Last, enable routing between the virtual network and the on-premise network

Set-NetIPInterface -InterfaceAlias "Etherprise1" -Forwarding Enabled

Set-NetIPInterface -InterfaceAlias "Ethernet" -Forwarding Enabled

On-prem router configuration

The enterprise must configure a static route on the router so that all packets that are destined for must be sent to, something like:

Add route Destination Next Hop

The exact syntax is of course dependent on the make/model of the router.


In this blog, we walked through a typical hybrid networking use case and demonstrate how an enterprise can connect the on-premise network to the virtual network hosted on a service provider’s datacenter. MPLS is assumed to be the service used to connect the enterprise’s datacenter and the service provider’s datacenter. In a slightly different scenario, the enterprise may use site-to-site VPN to connect to the service provider. If the service provider uses a 3rd party VPN appliance to terminate the site-to-site VPN tunnel, it can follow the same design described in this blog to “tunnel” the enterprise’s traffic from the 3rd party VPN appliance to a multilayer switch and connect to the enterprise’s virtual network through a Windows Server gateway. Similarly, an enterprise can follow the same design and use Windows Server Gateway to forward traffic between a non-virtualized network and a virtualized network.

Charley Wen, Program Manager, Windows Core Networking