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

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

  • Comments 5
  • Likes

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.

Introduction

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.

image

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

image

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 10.20.2.2 -PrefixLength 24 

10.20.2.2 is the gateway IP address for this enterprise’s virtual network.

New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 10.10.10.10 -PrefixLength 24

10.10.10.10 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 10.20.1.0/24
 -NextHop 10.20.2.1 

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

New-NetRoute -InterfaceAlias "Ethernet" -DestinationPrefix 0.0.0.0/0 -NextHop 10.10.10.1

This route says any other packets should be sent to the on-premise network. 10.10.10.1 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 10.10.10.10, 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 10.20.1.0/24 must be sent to 10.10.10.10, something like:

Add route Destination 10.20.1.0/24 Next Hop 10.10.10.10

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

Summary

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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Thanks for this informative blog.  I am interested in implementing the "Windows Server Gateway" in a private cloud (internal hyper-v environment) using Windows Server 2012 R2 and System Center Virtual Machine Manager 2012 R2.  Is there a guide available on how to implement a Gateway in a private cloud where the traffic between the virtualized network and the physical network needs to be forwarded/routed?

    Thanks

    AhmedSayani@yahoo.com

  • Thanks for the informative guide!

    Could it be that in the Set-VMNetworkAdapterVlan cmd the parameter to indicate the NIC name is -VMNetworkAdapterName instead of -Name?

    Cheers

  • Doing this using SCVMM 2012 R2.  Do you have a walkthrough of exactly the same setup using VMM?

  • Can you please clarify if this gateway VM is running on the same NVGRE network? I think one vNIC connected to NVGRE switch and other one connected to External NIC with multi-tenant stack "OFF"? Thanks! Dave