Fun with Funneling

The Case for Funneling Network Traffic with Basic Walk-through

@Carl Boisson
Tech Jobs Academy
6 min readApr 20, 2016

--

Image credit: Carl Boisson

This article assumes that you’ve previously installed and configured Windows Server 2012 and have a basic understanding of network traffic in a server environment, specifically, when working with Virtual Machines (VMs).

Leaky Pipes

Today, I’d like to make the case for funneling network traffic in an Active Directory (AD) domain. What I mean by funneling is channeling external internet traffic to specific Points-Of-Entry/Points-Of-Exit (POE). Specifically, ensuring that there are limited means of internet access and reducing the workload of DNS servers.

DNS servers facilitate communication between computers, whether through the internet or specifically in an AD environment. These are servers whose roles are resolving (read: translating) computer names to IP addresses. (If you’d like to learn more on DNS, you can read my blog post on the subject, it will make this post easier to follow). In an AD environment, DNS servers resolve names of computers and resources within the intranet. Specifically, they allow member servers and clients to “know” who their Domain Controllers (DC) are for purposes of authentication (login), acquiring group policy, or joining domains.

Active Directory, as administered in a branch office, may involve thousands of clients/servers trying to “speak” to dozens of domain controllers, with DNS as the backbone of all this “chatting”. This means these servers have their work cut out for them. If we’re able to funnel external (internet) traffic to specific DNS servers we’ve reserved for that purpose, we would reduce the load on those handling the communication within a domain. We would also be creating specific POEs to the internet which would ease the monitoring of traffic and pinpoint security threats.

For my example, I’ve pre-made a small AD environment in Hyper-V which includes:

  • Forest root domain controller: [FDC1] |Roles: ADDS+DNS|
  • 2 Child domain controllers: [CDC1]+[CDC2] |Roles: ADDS+DNS|
  • DHCP server: [DHCP1] |Roles: DHCP|
  • File server: [FileSrv1] |Roles: File and Storage Services|
  • Clients: [Win10_Client] [Win8_Client] [Win7_Client]

As it stands, none of these VMs have internet access. However, three of them have the DNS role installed, as they’re all domain controllers (DNS is required on at least 1 DC in a domain). They’re all configured with a single virtual adapter that is set to private. This means they can communicate with each other, but have no access to the outside world (the internet).

All VMs are using private switches, therefore, no internet access.

Let’s Re-flow

In order to introduce internet access to this network, I created a VM that would serve as the router (default gateway) on my network. A router is a server which performs a set of services which pertain to computers communicating across different networks.

  • Router: [RTR1] Roles: RRaS+DNS

The Routing and Remote Access (RRaS) role will facilitate internet access. One of the services a router performs is Network Address Translation (NAT). The IP addresses within an intranet are usually private, this means they’re valid for use within the network, but won’t be recognized on the internet. NAT “converts” these private IPs to public addresses (usually provided by Internet Service Providers) to enable communication with computers on the internet.

With a router in place and configured, internet access has been granted on our domain.

As stated prior, all the VMs in this example network have private virtual adapters coupled with private IP addresses. RTR1 has one as well and was placed in the same network, so it can communicate with the other VMs. In addition, I assigned it an external virtual adapter which does have the ability to communicate externally (the internet). This server can now receive the request for an internet address through the private virtual adapter, and route it through the external (public) adapter.

RTR1 is on a public and private network, hence the two adapters seen in network settings

Forming The Funnel

Now that we’ve established internet access, there’s still one thing to address. By default, all of the servers with the DNS role store a directory of entries to facilitate resolution of internet addresses. These are referred to as Root Hints (more detail on this can be found in a previous post). In order to ensure that only specific DNS servers can resolve internet addresses (RTR1), I disabled and removed root hints on ALL of my DNS servers except for one. Let’s walk through that process.

Quick Guide

Note: It would be best practice to create checkpoints on all your VMs at this stage.

  1. Disable Root Hints [Perform on all DNS servers except for 1]
  • From Server Manager: Select “Tools”, then “DNS”.
  • Expand all relevant DNS servers: Right-click the DNS server icon (i.e. CDC1).
  • Select “Properties
  • From DNS Properties:
    Click the “Forwarders” tab.
    Deselect “Use root hints if no forwarders are available”.
  • From DNS Properties:
    Click the “Root Hints” tab.
    Select “Remove” for all root hints.
    Click “OK”.

2. Add the new router’s IP address to your DNS settings in DHCP
[This step assumes you’ve set up a router and DHCP, you can do this manually on each VM if you’re not using DHCP].

  • From Server Manager [on your DHCP server]:
    Select “Tools”, then “DHCP
  • From DHCP:
    Expand IPv4.
    Expand all pertinent scopes.
    Right-click “Scope Options”.
    Select “Configure Options”.
  • From Scope Options:
    Click “006 DNS Servers”.
    Add the IP address of your router [the one you’ve kept Root Hints on].
    Click “OK”.

3. Ensure all VMs recognize the new DNS server. [If you’ve added the new IP manually, outside of DHCP scope settings, you can skip this step]

  • From any of your VMs [which are in the DHCP scope]:
    Run an elevated Command Prompt.
    Type “ipconfig /release” (this releases IP addresses and settings, including DNS servers).
    Hit “Enter”.
  • From an elevated Command Prompt:
    Type “ipconfig /renew” (this requests IP settings from the DHCP server).
    Verify the IP address of your new Router/DNS server is displayed.
    Close Command Prompt.
  • From any browser:
    Verify internet connectivity.

Funnel Master

Now that you’ve directed all your network traffic to one server, it will be easier to monitor and resolve any issues pertaining to external access. Your Domain Controllers (and other DNS servers not specifically assigned to resolve internet addresses) are now more available to resolve addresses on your intranet and you’ve mitigated potential bandwidth bottlenecks. If you’re interested in learning more on any of the topics we’ve touched today, I’ve included some links as well as key terms below. Thank you for reading!

Additional Resources:
Routing/Remote Access |Disabling Recursion |Root Hints

Key Terms:
Active Directory
Authentication
Bandwidth
Bottleneck
Command Prompt
Default Gateway
DNS Server
Group Policy
Hyper-V
Internet
Intranet
IP Address
Ipconfig
NAT
Root Hints
RRaS
Virtual Adapter
Virtual Machines

--

--