none
Isolate local test lab traffic from office network RRS feed

  • Pertanyaan

  • I have just set up a Hyper-V test lab on my office workstation for the purpose of testing network changes prior to implementation. The lab has a host server running Windows Server 2016 with DHCP, DNS, Windows Deployment Service and Active Directory. There are also 2 clients running Windows 10. Currently the lab is on a Private switch, so there is no risk of its traffic bleeding into my office network. I'm at the point where I need to connect this test lab to the internet, but in a way that there is no risk of introducing its traffic, rogue DHCP servers, DNS explosions or any other assorted goodies onto my office's production network. My workstation hosting this test network is a client on my office network which has a Windows 2012 R2 server also running DHCP, DNS and AD, so there's plenty to go wrong if don't do this properly. I've set my lab on a different subnet, 192.168.10.# vs the office's 192.168.20.#. I'm not sure if this is sufficient, or if there's more that I'm missing. 

    I know I'm not the first person to do this, but despite all my searching, I can't seem to find anything that addresses my particular configuration. I'm still new to this, though, so maybe I'm not searching the right terms. Also, if someone knows a good tutorial to point me toward, that would be great too.

    Thanks.


    • Diedit oleh Dr_Snooz Rabu, 11 Desember 2019 18.52
    Jumat, 06 Desember 2019 20.27

Semua Balasan

  • Hi

    would creating a NAT Virtual Switch on Hyper-V and then only allowing port 80 work for you? It would give you the isolation you require and you would still have your internet access. You'd need to move all of your VMs onto this network.

    Do a google search for "using-nat-virtual-switch-hyper-v" - you'll hit a link to an article by Aidan Finn that should bring you in the right direction.

    Only other suggestion would be to do this using a fully isolated network/vlan delivered from your firewall/router/tor switches and create another external network in Hyper-V to service these machines. Option 1 looks easier to me though ;)

    Thanks

    Michael

    Sabtu, 07 Desember 2019 00.22
  • Thank you for your help. That does appear to be what I'm looking for. Can you tell me what security considerations I should anticipate when I do this?
    Selasa, 10 Desember 2019 16.28
  • Hi

    glad to hear that its what you needed.

    The security considerations are pretty much opening up whatever ports you need for external access. On a NAT enabled vSwitch, there is no inbound or outbound traffic allowed - you need to enable the ports that you want for the VMs in vSwitch network to communicate via the physical adapter on your Host and then out to the outside world. 

    This is the official Microsoft article:

    https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/setup-nat-network

    This is Aidan Finn's follow up to the original one I referenced:

    https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/setup-nat-network

    As always, I would advise that you test this first before unleashing into your production environment. Easy way to do this is install the Hyper-V role on Windows 10, create a VM and test setting up the vSwitch and opening ports. Most of the examples you will see on Technet/Google deal with accessing VMs that are on NAT Networks and not the other way around.

    Thanks

    Michael

    Selasa, 10 Desember 2019 17.44
  • I recently learned that "VLAN" is a technical term for a network traffic management strategy unrelated to what I'm doing here. I've updated my original post to reflect more accurately what I'm working on. Thanks again for the help. 
    Rabu, 11 Desember 2019 18.54

  • Only other suggestion would be to do this using a fully isolated network/vlan delivered from your firewall/router/tor switches and create another external network in Hyper-V to service these machines. Option 1 looks easier to me though ;)


    The VLAN method would be the 2nd way to do it as per my original post. If you have multiple NICs in your host and either have one spare or have the ability to take one out of a SET/LBFO Team, then you can just isolate all traffic fully and tag the VLAN on your test network so that there is no leakage into your Corporate Environment. So in Hyper-V, you would be creating an External vSwitch and adding a VLAN tag to it. You then need to make sure on your Physical Network that this VLAN is just going directly to the internet and not leaking into your corporate environment.

    Using a NAT vSwitch and opening ports in Hyper-V will achieve the same thing for you but just at Hyper-V level, so its effectively Software Defined Networking. The only difference is that the Internet access is being introduced into your corporate network, so thats where the port lockdown is vitally important to get right. Hence my suggestion that you install Hyper-V role and a VM on a Windows 10 machine where you can see if this works for you.

    Kamis, 12 Desember 2019 10.13
  • Success!!! ...sort of. Using Aidan Finn's article, the office network clients cannot see my test lab VM clients, but my test lab VM clients CAN see my network clients. So I'm halfway there. My office network won't have a rogue DHCP server, but my test lab network will. You mention port lockdown as another piece of this. What should I do there?

    The test lab is on my Win10 machine with Hyper-V installed. I'm trying to allow the test lab to tunnel out to the internet without interfering with any other network traffic. 

    The other method is to go ask mgmt to spend some money on a separate server to house the test lab, with a direct connection to the main router and some configuration on the router to isolate the two networks. It seems like there are a lot more ways to isolate traffic at the router level than at the client level. I've already begun lobbying for a separate server setup with mgmt, but would like to figure out something quick and free so I can continue testing while they discuss it. 

    Jumat, 13 Desember 2019 19.21
  • Well I'm feeling pretty silly right now. I noticed this sentence on the Default Switch in my Hyper-V Switch Manager.

    Hyper-V Default Switch NAT Capability

    It's that sentence at the bottom about NAT. If I'm understanding NAT correctly, it should do exactly what I need: set a hard boundary around my virtual network that designates everything on the Default Switch as friendly network, and everything outside the Default Switch as unfriendly internet. 

    That's exactly what it appears to do. On the Default Switch, my test VM is definitely not being seen by my network; is definitely not getting its IP address from our DHCP server. I’m not able to ping it from my workstation, nor am I able to ping it from another client on my network. The VM is able to ping my network clients, but is not able to establish a Remote Desktop session. 

    Everything I needed appears to have been there all along. I was so busy trying to re-invent what was already there that I never noticed it! Is there anything I'm missing here, or is this really the solution to my problem?

    Jumat, 20 Desember 2019 19.49
  • I've tested this every which way I know and the test network is completely isolated from the office network using Hyper-V's Default Switch. I can use it without fear of introducing any rogue DHCP servers or other assorted nastiness onto the office network. Thanks all for your help and Merry Christmas!
    Selasa, 24 Desember 2019 14.48
  • Nevermind. Apparently, MSFT's Default Switch has a wonderful feature that turns off internet access when you move to a static IP address. My test network was isolated because all traffic out of the network had been turned off. You could set up a Workgroup, possibly, but a server environment is impossible. 

    The NAT switch proposed by Michael above does NOT entirely isolate the VM network, as I'm able to remote into specific IP addresses on the office network from the VMs (though not the other direction). I haven't found in my testing so far that DHCP assignment gets confused on either network, but it's still disconcerting. A physically isolated system would be preferable in my opinion. 

    Kamis, 26 Desember 2019 15.11
  • You stated in an earlier reply that VLANs are unrelated to what you are trying to do.  I don't understand why you make that statement because putting your test environment on a VLAN would easily isolate that network.  VLANs were designed for that exact scenario.


    tim

    Jumat, 27 Desember 2019 14.04
  • I guess because some of the tech guys I talked to got real confused when I used the term, and all the Google searching kept bringing up network traffic load balancing links. I'm not trying to load balance; I'm trying to isolate. Call it whatever gets me across the finish line, I guess. Am I not on a VLAN right now?

    Senin, 30 Desember 2019 15.28
  • I can't tell if you are on a VLAN or not.  No way to tell from here.  A VLAN is a LAN within a LAN - a virtual LAN.  A VLAN has a numerical 'tag' on each packet it sends out.  Only those machines that are configured to recognize this tag can participate in the VLAN.  So on a physical network segment, you could actually have two (or more) networks using a particular IP subnet.  Let's use 192.168.1.0/24.  By default, the network packets are not tagged, so anyone configured in a default manner on 192.168.1.0/24 sees packets in that subnet.  However, if a VLAN is defined to be tagged with the number 24, then only those machines that are configured to recognize that tag will be able to see packets with that tag, even if those tagged packets are also using the 192.168.1.0/24 subnet.  Generally VLANs are configured on different subnets, but tagging makes it possible for two (or more) networks to have the same IP addressing range.

    So in your situation where you want to set up an alternate DHCP on a physical network that already has DHCP, that is no issue.  You simply define a VLAN and tag the packets.  Only those machines that are configured for that VLAN recognize packets on that VLAN so it is impossible for a machine not configured for the VLAN to see anything configured on that VLAN.  VLANs are often used for security reasons to isolate networks from other networks.  

    VLANs are tagged from 1-4095.  All components, switches and NICs, need to be configured for VLANs to work.

    VLANs have nothing to do with network load balancing.  They can be used in network load balancing environments, but that's because they can be used in any networking situation.  

    In small shops, it is not uncommon to never use VLANs.  I got by for years without any knowledge of VLANs.  But as you get into more complex networking environments, VLANs become very handy.

    If you want to learn about VLANs, http://www.ciscopress.com/articles/article.asp?p=2181837 is a good place to start.  Most likely more information than you need, but the introduction in there may give you a better understanding.


    tim

    Selasa, 31 Desember 2019 14.13
  • Thank you for that link. When I first saw the VLAN ID checkbox in Hyper-V, I suspected it was meant to address my need. When I did my web searching though, I couldn't find any links that spoke to my specific situation of creating a VLAN on a client machine. That coupled with all the web links about load balancing and the blank stares I got from other IT guys, convinced me that I was on the wrong track.

    My question was what happens after my VLAN packets percolate up from the bowels of my client machine and land on the office network. After doing a little more research, I realize that I was overthinking it. With Hyper-V, I haven't created a VLAN on a client machine. I've only added a few VMs to the office network. They look like clients on my office network, not something magical happening on a network client. I don't know why it took so long to make that intuitive leap. 

    I assume I need a dedicated NIC because Hyper-V keeps getting stinky about connecting anything other than the Default Switch to my existing NIC. I'll round up another NIC and switch and see what happens. Stay tuned for more.

    Thank you again and Happy New Year!


    Kamis, 02 Januari 2020 17.00
  • It doesn't work, sadly. If your network hardware doesn't support VLAN tagging, then the traffic isolation is total, as in, it doesn't work at all (http://itproctology.blogspot.com/2009/03/hyper-v-and-vlans.html). Our hardware is old; we want to make changes; hence the need for a good test network. So the only way left to isolate this traffic is with subnetting, which is sort of where I started. Can someone point me to a resource for best practices in setting this up?
    • Diedit oleh Dr_Snooz Jumat, 10 Januari 2020 18.53
    Jumat, 10 Januari 2020 18.52
  • Interesting.  VLAN is an older technology, defined in the early 2000s.  I'm surprised you have equipment that does not support it.  I suppose consumer-grade routers/switches may not implement, but equipment designed for business use will usually have it.

    "Can someone point me to a resource for best practices in setting this up?"

    I don't know if there is such a document because subnetting is pretty straightforward.  You simply put in a different subnet.  But that doesn't address DHCP.  A request for a DHCP address is broadcast that goes out on the physical network and is not directed to a specific subnet.  So if you have a DHCP server on the physical network serving 192.168.1.0/24 and another DHCP server on the same physical network serving 192.168.2.0/24, either DHCP server can respond to the request.  That is where VLANs come in.  Only traffic tagged with the appropriate VLAN is seen by nodes properly configured for that VLAN.

    So, if you do not have the abiity to use VLANs, the only way to isolate the traffice is to place your test network on a completely different cable segment.l


    tim

    Sabtu, 11 Januari 2020 14.39