Oh... the best thing I did in my state of lunacy? I did a System Restore on my machine while trying to fix a program, not realizing what it would do to the virtual hard disks in Hyper-V. It actually wasn't as bad as I thought it would be... but take my advice and don't ever do that.
Of course, I'm still going to post something... so I picked something that's entertaining by itself. Now I don't have to be.
Expect lots of typos and omitted words, sentences, paragraphs, etc. In fact, if I manage to hit the Publish button at all, I'll be ecstatic tomorrow.
Meet pfSense
Now, I'm sure plenty of readers have "met" pfSense and know it pretty well, but this is a Microsoft-centric blog. The idea of using something that's not Microsoft, not even Linux, but *gasp* Unix-based via FreeBSD can be a little jarring. It's a whole different planet.
When I finally got to start planning out my lab, I knew right off the bat that the environment wasn't going to be simple. It was going to be extremely complex. I wanted to run into problems and learn why they occur and how to fix them and how to prevent them. So I just started slicing up the network into a bunch of different subnets. Of course, with different subnets comes the need for routers.
When you're dealing with virtual machines and shared adapters, the concept of routing gets a little fuzzy. Of course, that didn't stop me. I just threw a whole lot of RRAS at the problem. But using Routing and Remote Access, outside of DirectAccess and VPN infrastructure, creates a problem in itself. To be clear, there's nothing really wrong with RRAS routers... but there's not a whole lot right either. That's because there just isn't much of anything. They're super simple services running on the backbone of Windows Server like a fly on a giant's back. I quickly realized it wasn't ideal.
I also had a bunch of other hurdles to get over. I'd come up with a solution for one problem and then another and another, all the while making progress, sure, but not really seeing the big picture. I had questions like these:
- How can I reduce the overhead on all these RRAS "routers", each one running a full server operating system? (I tried Server Core but RRAS loses almost all functionality.)
- Without having to use Threat Management Gateway 2010, which I hate and is on its last breath, how will I direct traffic to internal servers which use the same port?
- How will I handle things like low-layer firewalling and load-balancing beyond DNS round robin?
- How can I tighten security but not be overly intrusive?
- How can I gain better control over the traffic coming in from the WAN when I'm stuck with a crappy modem/router from Time Warner Cable?
- Should I buy more hard drives or pay rent for once?
It was pretty frustrating. The tools I'd discover would cost too much or overlap poorly with something else or be more trouble than it was worth.
And then... I discovered pfSense. It did not have those issues... and not only did it satisfy all of the criteria listed above... it added about 100 times more functionality than what I had even dreamed of. And all of that for the low, low cost of absolutely nothing.
The Free Firewall, Router, Switch, Proxy, Reverse Proxy, Load Balancer, Remote Access Server, Traffic Sniffer, Packet Inspector, Antivirus, Toolbox, IDS, IPS, and Master of L2 Transparency
pfSense. It's the love of my life.
Honestly, I think that it is the best testament to open-source development in any arena. I could just keep on gushing, but you get the point. It's just the greats!
And you may be thinking, "Wow. That's gotta be ridiculously hard to set up." Wrong. Those features aren't what made it so popular. What made it popular is how it can walk the greenest networking guy or gal through the initial configuration in about 30 minutes. You can have a working router and firewall on the network in less time than it takes to get pizza delivered.
All that being said, it starts to get a little finicky when you try to bring it in the Microsoft hypervisor platform. VMware? No problem. Embedded kernel on custom hardware? Perfection. But with Hyper-V, you have to learn some tricks. I'll teach you some of these while I walk through the process of replacing one of my RRAS routers with a shiny new FreeBSD bad boy.
A Version for Every Occasion... okay, well, actually just two occasions
Running pfSense on Hyper-V, one of the issues you'll see is that the virtual network adapters need some special consideration. For the network cards and some other components, their configuration will vary based on the version.
There are currently two popular releases of pfSense:
- 2.1.5 Full Release
- 2.2.0 Beta
If you're reading this before the official release of 2.2.0, the decision on which one to pick is simple.
If you are only going to use it for simple purposes such as a router, switch, or firewall:
Use the beta version, 2.2.0.
The reason is that the virtual NICs will work without any special treatment. However, there aren't very many packages available for this version yet, so you're stuck with the features included by default. This will change in the future. The 2.2.0 full release should be a pretty great improvement.
If you would like to configure advanced features like forward/reverse proxy (such as for Lync Server 2013), IDS, inspection of certificates and protocols, antivirus, etc:
Use 2.1.5.
All of the really advanced features are developed by third parties and they generally do not match their update cycles with beta releases. For version 2.1.5, you must use Legacy Network Adapters in Hyper-V. This isn't a major inconvenience, but occasionally you will have to go into the shell to cycle the interfaces to resume connectivity. They also seem to respond to certain interface bindings differently, but this could just be the version difference.
You can find both versions at https://www.pfsense.org/download/. You want the LiveCD option because Hyper-V can not read .img files.
Configuring the Virtual Machine Settings
Note: Despite what I said above, I am going to use 2.1.5 for this router so that I can show legacy NIC setup.
1. Let's create the VM. In Hyper-V Manager, select New --> Virtual Machine in the right column.
2. Specify the name to be displayed in Hyper-V (and SCVMM, if applicable) and choose a location for the configuration files. Click Next.
3. You must select Generation 1 because pfSense runs on FreeBSD. Click Next.
4. 512 MB of memory, non-dynamic, is more than enough for pfSense. You could honestly get away with dropping it down even lower, perhaps as far down as 128 MB.
With those RRAS routers I was running, they would regularly suck up more than a GB of RAM. That's way too much for a networking device.
Click Next.
5. If you are going to install the 2.2.0 Beta, go ahead and select a Virtual Switch. If you are using 2.1.5 like I will be, it doesn't matter what you put here because we're going to delete this adapter anyway. Click Next.
6. The hard disk size doesn't need to be any larger than 4-5 GB for a simple router or firewall. If you plan on going a little nuts with the add-on packages, bump it up to 10 GB or so. That definitely smokes the space requirements of RRAS.
One thing I like to do is create fixed-size disks, or "thick provisioned" disks as they're called with VMware, when they are this small. The standard VHDX created from the wizard is a dynamically-expanding disk. It will display the total size within the guest, but it only takes up space on the Hyper-V host for actual data within the disk. Fixed disks are faster and there isn't much of a downside with such low disk requirements.
If you would also like to create a fixed disk, select "Attach a virtual hard disk later."
Feel free to review the summary by hitting Next or just finish the wizard by hitting Finish.
7. Right-click the newly-created VM and click Settings...
8. Ah, yes. The Settings window.
If you just did a dynamically-expanding disk in step 6, skip on ahead to step 9.
This is how you create the fixed-size disk:
Click the "IDE Controller 0" line.
With "Hard Drive" selected, click Add.
For "Virtual Hard Disk", click New.
Click Next at "Before You Begin" and at "Choose Disk Format." We're using the VHDX format.
At the "Choose Disk Type" screen, select "Fixed size." Click Next.
Give it a name and location. Click Next.
Under "Create a new blank virtual hard disk", enter the size of the new disk in GB. 4 is enough for a router/firewall. Give yourself 10 GB if you're setting up advanced features.
Click Next to see the summary or Finish to complete the wizard. It can take a few minutes to create the disk, so go grab a donut.
9. If you are using versions 2.1.5, select "Network Adapter" and then click Remove on the right side of the window.
We now need to add our network adapters by clicking "Add Hardware" at the top of the column.
If you are using the 2.2.0 Beta, just select "Network Adapter" and click Add. Keep in mind that you already set one up during VM creation.
For version 2.1.5, select "Legacy Network Adapter" and click Add.
It automatically brings you to the configuration screen for that adapter. Select a Virtual Switch to connect to:
Create as many adapters as you need. It's important to note that you are limited to 4 adapters when you use Legacy NICs.
10. Select DVD Drive in the column. Under Media, select "Image file", then click Browse. Find your pfSense ISO (it's zipped when you download it).
Click Open.
11. You may optionally add a few logical cores to the machine from your host's processor:
12. Finally, scroll down to "Automatic Start Action" in the column:
Set the machine to automatically start at the 0 second mark. 0 should be reserved for very important services that all the other machines depend on. Things with fewer dependencies but still considerably important, like SQL Server, should start at 30 seconds to a minute. Pretty much everything else can be set to 120 seconds, or longer if your VMs take their sweet time waking up.
Here is everything that is changing in my settings (except for Auto-Start):
Click OK when you're ready.
Installing pfSense
1. In Hyper-V Manager, right-click the VM and click Start.
By the way, this is what it looks like when you run out of RAM on your server. Oops. =)
AND with that, I think we've found a great stopping point! Looks like I just turned this into a series article.
However, I am going to use this as an opportunity to show how to fix this. Fortunately, I have another node I can move to. If this was your only server, I would recommend configuring dynamic memory on your other VMs. If their desired resources are exceeding the allotted maximum dynamic memory, it's a sign that you're stretching yourself too thin as is.
Running Out of RAM on a Hyper-V Node
As you saw above, I ran out of RAM on one of my servers. Given that the new machine only had 512 MB of RAM and my nodes have 32 GB each, I'd say I sized the machine pretty well.
So the simple solution is to move stuff around and make it all fit. But wait a second! Let's check Task Manager.
Why wouldn't it fit?! It's only at 91% utilization.
Here's why:
 |
| This is a live Performance Monitor report pulled from Hyper-V's performance counters. |
Starting in Server 2012, they changed the way that memory is allocated between the host and its guests. Basically, you shouldn't be worried about the host running out of memory, which means fewer STOP errors and less crying. The reason that there is a large disparity between "available RAM" between these two sources is because Hyper-V is accounting for spiking. This is called buffering for a virtual machine--giving it more RAM that it doesn't need in case it suddenly needs it.
As far as moving this VM off the server, it's pretty straight-forward. Right-click the server and select "Move..."
Move its storage (the first option is for a Hyper-V Failover Cluster)...
You can pick anything you want on the next screen. You might be picky about folder placement. Honestly, though, the config files can be on an entirely different server and this would still work. I'm just going to do "single location."
For the new location, I don't recommend putting it somewhere temporarily to grab it later. Just a) connect to a share on the destination computer, b) configure a share to use, or c) move it to another location on the source computer, then cut and paste. You do 'c' if you can't figure out which configuration and/or snapshot file belongs to that VM. Honestly, straight up file transfer is better. It's just nice to be able to perform the move operation because the machine can stay up while it transfers.
Click below to continue to part two:
Click below to continue to part two:
No comments:
Post a Comment