It seems like I’ve always got a few different environments running in Hyper-V, each with their own DNS, DHCP, Active Directory, etc. running in them.  And in today’s cloud-connected world, they can’t just be isolated environments, they need to have internet access.  To simulate something close to “real-world” environments, I usually set up a server specifically for routing between these environments and the internet, without allowing any communication between them.  While I’m sure there are plenty of solutions out there that allow for this, I typically stick with Windows Server and RRAS for doing this.  Unlike other RRAS configurations (e.g. Always On VPN) this one is fairly easy to set up.  Start off with a VM running Windows Server 2019 (older versions work fine too) joined to a workgroup, with two virtual network adapters attached.  One should be connected to a network that has internet access, so I’ll name that connection “Internet,” and the other should be connected to the internal environment’s network, named appropriately for that environment, e.g. “West Lab.”  Configure the internal network connection with a static IP address that is appropriate for that network.  I typically use 10.*.1.254 (replacing the asterisk with an environment-specific number), where that “254” address is then excluded from the DHCP range on that network.  (Occasionally, I will use multiple subnets for a single internal environment, hence the 10.*.1 could be accompanied by a 10.*.2, 10.*.3, etc.  But that’s a more advanced scenario.  RRAS can be set up to route between multiple segments too, so the same server can be used for that.)

If you had multiple environments, you would need to set up multiple of these internal “Lab” connections.  If you choose to add an additional lab later, you can easily come back and add a new virtual NIC to the existing server – one “router” that works for all environments.

Technically, this server is only going to be doing network address translation (NAT), allowing all the internal hosts to use a single IP address for accessing the outside world.  But as that’s very much like a “real” corporate network, that works well.

If by chance you need to connect a “real” device to one of these lab networks, you can use a spare Ethernet port in the server (USB, PCIe, etc. work fine) instead of a Hyper-V internal network.  You could even connect that Ethernet port to a Wi-Fi access point (seems like I’ve got several of those laying around) if you need wireless access.

Enough background, let’s get started with the configuration.  First, let’s verify the network configuration on my server:

So the “West Lab” network has a static IP address of 10.101.1.254, and the Internet connection is picking up a DHCP

Next, we need to add the Remote Access (a.k.a. RRAS) feature to the server using Server Manager.  (You can use PowerShell too if you’d like.) 

We really only want the “Routing” role service, but when you select that it will also select DirectAccess and VPN.  That’s OK, since you don’t have to configure those (and you really don’t want to configure those on a workgroup machine, they’re much more useful on an AD-joined server, hence if you want to set one up it would be environment-specific).  It will also add IIS and other components – just take all the defaults to install those pre-reqs.

Normally after the feature is installed you would configuring it by clicking the “Open the Getting Started Wizard” link:

That would display a configuration wizard:

Since we don’t want any of those (we are doing a NAT router), just close this wizard.  Instead, open the “Routing and Remote Access” tool, right-click on the server name, and choose the “Configure and Enable Routing and Remote Access” context menu option.

In the resulting wizard, choose NAT:

You can then select the “Internet” connection:

And with that, you’re ready to go – almost.  If you go to a device on that internal network, e.g. the domain controller (which, yes, is an old environment still running Server 2012 R2 – I should probably upgrade that), you can see that it is able to get to the internet by pinging a remote machine (where 8.8.8.8 is Google’s DNS server):

But if you launched a web browser, you might find that it doesn’t work.  That’s because the internal DNS needs to know how to forward requests to the internet.  I configured mine to point to Comcast’s DNS server, but any public DNS server would work fine:

That’s all it takes.  Compared to DirectAccess or Always On VPN, this is an easy one.