Homelab Learning: Building a corporate environment within your Proxmox VE homelab

Evyn Hedgpeth
6 min readJul 6, 2023

--

Hi, all. This is the fourth part in an ongoing series walking through the steps required to build my isolated homelab with a corporate environment, attack network, security operations center, and remote access VPN.

For greater context, take a look at my previous posts:

  1. Homelab Learning: General Overview
  2. Homelab Learning: Configuring Proxmox VE
  3. Homelab Learning: Configuring pfSense

Let’s get started on this installment!

This is the subnet we’ll be focusing on in this post.

Building a Corporate Environment

Considering my objectives to learn about red and blue team tools and methodologies, the corporate environment is an essential educational sandbox. During construction, I learned the ins and outs of Microsoft Active Directory, including creating a domain and promoting a Domain Controller, and confirmed my knowledge of IT fundamentals by configuring DHCP and DNS servers.

Configuring Windows Server 2019 VM

This process is pretty straightforward and applicable in a variety of environments, so I won’t be walking through it here. Please check references for a video tutorial.

Configuring Microsoft Active Directory, DNS, and DHCP

Again, this is well-trodden ground, so it is not necessary to re-hash here. I’ve attached a video tutorial in references for this as well. If it is your first time getting hands-on experience with any of these concepts, you may run into misconfiguration issues, but everything is resolvable with time and a bit of troubleshooting moxie.

After configuring Active Directory (AD), promoting the WS2019 host as the Domain Controller (DC), and configuring DHCP and DNS through that DC, we do not need pfSense to provide DHCP services for this interface anymore. In the FW-mgmt VM, go to the pfSense webGUI and disable the DHCP server on Corp_Env. At the bottom of the DHCP server page, add a static mapping for your Windows Server VM allowing it (its MAC address is available in Proxmox: Hardware -> Network Device -> MAC Address) on the IP address you specified (e.g., 10.0.2.2).

Configuring a Win10 Enterprise VM and joining it to the AD domain

Generally, the install for a Win10 client is not too different from the Windows Server install I completed above — in fact, I used the same video from Learn Linux TV to ensure my setup/config was correct. Now, you can return to the ~14:20 mark of the MSFT WebCast walkthrough for joining this Win10 Ent client to your domain. ***If you have issues with this, see my notes below.

At this point, I had also changed the default device name in Settings –> About to have a more scalable name — WIN10-CLI01. To make signing in a bit easier, I also enabled Windows Hello PIN in Sign-in Options. These changes will require a reboot.

Now, you should see the WIN10-CLI01 lease in your Windows Server DHCP leases and under AD Users and Computers.

Et voila! We have created a corporate environment. Although this is about the smallest a corporate environment could be, we’ve constructed a scalable framework for future projects (introducing vulnerable VMs from vulnhub, implementing BadBlood, etc.).

Corporate Environment notes

Note 1: If you disabled the DHCP server as I previously recommended, you will likely not have a network connection. Remember, in this network, we want to receive our DHCP and DNS from the Windows Server/AD Domain Controller rather than pfSense. In my case, I spun up this VM before disabling the DHCP server in pfSense, so it took me a few minutes (and reboots) to shake the initial DHCP lease from pfSense. Once I ensured the WinEnt10 client IPv4 settings were correct (receiving an IP in the range I configured through AD), I joined the mylab.local domain.

Note 2: Around 17:00 in the MSFT WebCast walkthrough, I did not have the option to “Join Azure AD.” Instead, I needed to search ‘domain’ before going to “Add work or school,” clicking Connect, and selecting “Join this device to a local Active Directory domain.” From there, I typed in mylab followed by the Administrator info from my Windows Server VM — this part aligns with the walkthrough once again

Note 3: If you still experience difficulties joining this client to your AD domain, see my note on the offline join process in ‘challenges.’

Firewall Rule Methodology

Two main ideas will form the foundation of our firewall ruleset:

  • keep it short
  • default deny

As I alluded to above, an industry standard approach to firewall rulesets is to begin from an implicit deny viewpoint. Since pfSense does this by default, I only needed to focus on approving/passing the traffic that is necessary/desired. By keeping this ruleset short and as-needed, you can help ensure the scalability and manageability of the firewall.

At basic configuration, we can keep the Corp_Env firewall ruleset simple, since for now this network is only relying on internet access. First, we’re going to set up a firewall rule to allow HTTPS traffic. It is best practices to include a brief description of the rule and its purpose. This ensures that if more than one person are working on a firewall, or if a long time passes and you forget, you’ll be able to quickly reorient yourself to the various rules and their rationale. After completing the HTTPS firewall rule, do the same for HTTP traffic over port 80.

Next, we need to enable DNS resolution for this interface over port 53. For this, we’ll allow IPv4 TCP/UDP traffic from the CORP_ENV network to any over port 53.

Finally, I want to be able to ping other places for troubleshooting purposes. I’ll create one final rule allowing IPv4 ICMP traffic from this network to any over any port.

Ultimately, my firewall ruleset for CORP_ENV looked like this:

With the corporate environment up and running, much of the heavy lifting for the homelab is complete. Next, we’ll set up an attack network with a Kali Linux machine.

References:

--

--