Pardon the interruption. Once I got things up and running in my last post I got a little carried away with getting things up and running. I think it’s a good time to take a break to catch up on things here.
Like so many homelabs these days, mine begins with pfSense. Before I say anything else I just want to recommend that you give pfSense a solid look for your routing and firewall needs if you haven’t already. It’s such a solid project. I had always used pfSense for routing in the past, but then I had the great fortune of becoming a Google Fiber customer. Given that Google says you have to use their Fiber Box router for service, and given that my old pfSense hardware was recently deceased, I hadn’t thought too much about it until I started working on this project.
It turns out that it’s simple to get up and running with Google Fiber and pfSense. If you’ve arrived here looking for help with that, you’ll want to read my next post instead of this.
Before I could even think about getting Google Fiber up and running without Google’s Fiber Box I first needed to virtualize pfSense. Ideally I’d be running it on standalone hardware and I still want to do that. Right now, however, priorities and circumstances mean that virtualization makes the most sense for the moment. If you’re going down the same path, there are a few things you’ll want to consider:
- What’s your backup plan for the ESXi management interface?
- Make sure you configure pfSense for automatic startup in ESXi.
- A good UPS is mandatory.
Let’s start with point one regarding the ESXi management interface. This is really quite simple. If you connect to the ESXi management interface through pfSense, then you won’t have any access to ESXi if pfSense is down. This means that should your pfSens VM ever shutdown or go down for some reason, you’ll need to have a backup hardware router to connect the ESXi management interface to in order to access the ESXi web interface. Or you’ll have to restart pfSense via the ESXi console. Either way, this is something to consider so that you’re not dead in the water if pfSense goes down.
That brings me to my second point. If you don’t configure your pfSense VM for automatic startup, you’ll be stuck in the situation I mentioned above should you need to reboot ESXi (Ex: for patches) or shut it down. You want to make sure your pfSense VM is the first VM to come online and the last one to go down during an ESXi startup/shutdown. Otherwise you’ll need to connect a keyboard and display to your ESXi box, and what fun is that?
And that’s why our third point is important. Without a good UPS you’ll lose your ESXi host in a power outage/brownout situation. If we put aside all the potential corruption issues that would arise from this, you still have to note that you won’t have time to get your VMs to shutdown/restarted automatically. A UPS will allow you to detect a power outage and begin the automated shutdown process. I manage this through the open-source Network UPS Tools (NUT) project. I have a VM dedicated to operating as a NUT server, with ESXi and VMs acting as clients. pfSense has a NUT client package ready for configuration. Should my UPS report a power outage to my NUT server, the NUT server will monitor the battery status of the UPS and let clients know to begin shutting down when the battery level reaches a level I’ve designated as critical.
I’m sure there are other things to consider and this is a less than detailed post, but it should help get folks on the right track for thinking about virtualizing pfSense. If you have specific questions feel free to post them in the comments. I’ll do my best to help.