0

I am setting up a pretty decent server running Windows Server 2008 R2 to be a remote (colocated) Hyper-V host. It will be hosting Linux and Windows VMs, initially for developers to use but eventually also to do some web hosting and other tasks. Currently I have two VMs, one Windows and one Ubuntu Linux, running pretty well, and I plan to clone them for future use.

Right now I'm considering the best ways to configure developer and administrator access to the server once it is moved into the colocation facility, and I'm seeking advice on that. My thought is to set up a VPN for access to certain features of the VMs on the server, but I have a few different options for going about this:

Connect the server to an existing hardware firewall (an old-ish Netscreen 5-GT) that can create a VPN and map external IPs to the VMs, which will have their own IPs exposed through the virtual interface. One problem with this choice is that I'm the only one trained on the Netscreen, and its interface is a bit baroque, so others may have difficulty maintaining it. Advantage is that I already know how to do it, and I know it will do what I need.

Connect the server directly to the network and configure the Windows 2008 firewall to restrict access to the VMs and set up a VPN. I haven't done this before, so it will have a learning curve, but I'm willing to learn if this option is better long-term than the Netscreen. Another advantage is that I won't have to train anyone on the Netscreen interface. Still, I'm not certain if the capabilities of the Windows software firewall as far as creating VPNs, setting up rules for external access to certain ports on the IPs of Hyper-V servers, etc. Will it be sufficient for my needs and easy enough to set up / maintain?

Anything else? What are the limitations of my approaches? What are the best practices / what has worked well for you? Remember that I need to set up developer access as well as consumer access to some services. Is a VPN even the right choice?

Improve this question
2
  • 5
    Why are you using 2008 R2 in 2014 for this? Commented Apr 2, 2014 at 15:52
  • HyperV 2012r2 has a LOT of improvements to it. If you are just starting with hyperv start there! Commented Apr 2, 2014 at 22:04

2 Answers 2

Reset to default
0

I would personally have a separate physical firewall (Netscreen or whatever you're confortable with) that handles the VPN separately and invest in an out-of-band management system (like Dell's DRAC) to give you low-level access to your server (and firewall's console port if/when you want to update your firmware) in case of hung or crashed (trust me: this will happen) VMs or host, or when you want to do worry-free Windows Updates, etc.

The Netscreen should support IPSec mobile VPN access with an added benefit of two-factor (certificates and passphrases) for authentication. Been a while since I've used one, but I believe they have several VPN options available.

Going with a hardware firewall (or really, a "Unified Threat Management" appliance as firewalls with all the bells and whistles that most of them have nowadays) will also give you some flexibility down the road with regards to proxying SMTP/DNS requests, DMZs, etc. when you move to a production web hosting environment.

Improve this answer
0

Like the comment said, 2012 R2 is actually pretty solid for use in this scenario. As for remote access, each machine should have it's own remote access and shouldn't depend on the host or other VMs, meaning that you don't want to 'walk' anyone thorough adding your host on their Hyper-V manager to access their VM. If they can't remote desktop to it, then too bad.

That being said, one way I would go about that is setting up an internal DNS server that resolves the names of your VMs, and giving them access to the network segment with the VMs on it (which should be different than the segment your host sits on), and configure local auth on your VMs, and of course configure the firewall appropriately.

A VPN can surely accomplish this. You could even setup a VM that hosts a VPN server and bridges the two network segments. I'm partial to OpenVPN, but whatever floats your boat. The idea being that once they authenticate to your VPN that's the only way they'll have access to that network segment.

Digging further into the implementation details, the network segment your VMs are accessed on could be a virtual network on your host, and your virtual VPN server has both a leg in the virtual network, and a leg in the physical network, with the appropriate iptables config and OpenVPN config setup to allow the bridge.

Also, remember consumers are not the most computer-savvy folks, depending on your actual clients. You may even be able to setup a 'VNC Proxy', which in my implementation would be nothing more than glorified port forwarding, but it would suffice and be simple enough for a basic end user to d/l a VNC client and punch in an IP address and port.

I didn't dig into securing your internet accessible machines, but that would warrant an additional SF question.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.