When setting up a homelab that aims to replicate an enterprise-level network, one of the most critical tasks is configuring the network interfaces. These interfaces act as the lifelines for communication between different segments of our network, and their correct configuration is crucial for the seamless operation of our services.
I won’t be going over installing pfSense but I’d recommend checking out this YouTube video for some behind-the-scenes on how installing pfSense works. (187) How to Install pfSense – Start to Finish! – YouTube
In our pfSense setup, each network interface is purposefully designated to correspond with a virtual switch, creating a meticulously organized network topology. Here’s how they are set up:
WAN Interface (Associated with WAN Switch)
- IPv4 Configuration: Typically DHCP or static; specific to your ISP.
- Purpose: Serves as the entry and exit point for external internet traffic, with stringent security rules in place.
LAB Interface (Associated with LAB Switch)
- IPv4 Address: 192.168.80.1
- Subnet Mask: 255.255.255.0
- Address Pool: 192.168.80.10 to 192.168.80.254
- Domain Name: lab.mylocal
- Purpose: Handles traffic for general lab activities, providing a dynamic range of IP addresses for devices.
Management Interface (Associated with Management Switch)
- IPv4 Address: 192.168.90.1
- Subnet Mask: 255.255.255.0
- Address Pool: 192.168.90.10 to 192.168.90.254
- Domain Name: mgmt.mylocal
- Purpose: Dedicated to network management, it ensures secure access to management functions.
Pentest Interface (Associated with Pentest Switch)
- IPv4 Address: 192.168.70.1
- Subnet Mask: 255.255.255.0
- Address Pool: 192.168.70.10 to 192.168.70.254
- Domain Name: pentest.mylocal
- Purpose: Isolated network for penetration testing, providing a safe environment for security exercises.
Vuln Interface (Associated with Vuln Devices Switch)
- IPv4 Address: 192.168.60.1
- Subnet Mask: 255.255.255.0
- Address Pool: 192.168.60.10 to 192.168.60.254
- Domain Name: vuln.mylocal
- Purpose: Contains vulnerable machines for security training and testing, isolated for safety.
By setting up these interfaces and their corresponding switches, we’ve established a robust and segmented network within our homelab. Each interface serves a distinct purpose, ensuring that traffic is appropriately routed and that each segment operates within its intended scope.
For now, pfSense is operating as the DNS server using the DNS forwarder while the Windows server 2019 virtual machine, will act as the domain controller for the active directory and keep DNS records.
The backbone of network security in any homelab or enterprise environment is a well-structured set of firewall rules. For our LAB network, we’ve implemented a series of rules in pfSense to regulate traffic and ensure secure communications. Below, we will go over these rules as configured in our homelab’s pfSense firewall. One thing to note in these firewall rules is that 192.168.90.2 is the static IP set for our active directory virtual machine. I encourage you to read the screenshots of these firewall rules, Google the ports, and discover the methodology of this setup. To learn more about firewall rules I’d recommend reading this writeup (Put Your Firewall Rules In The Correct Order – NETWORK FUN-TIMES (networkfuntimes.com)). I’d also recommend learning what an asterisk does this writeup can help with that (Trellix Doc Portal).
LAB Interface Firewall Rules Overview
LAB to AD (Active Directory) Allow Rules
- These are a set of rules that mainly allow LAB subnets to our active directory services.
LAB to Management Block
- This rule prevents any direct traffic from the LAB subnets to the Management network, reinforcing the principle of least privilege and segmenting network management from general lab traffic.
LAB Specific Rules Allow
- These are general rules that allow LAB subnets to web browse and time synchronization.
LAB to * Block
- Acts as a catch-all to deny any traffic not explicitly allowed by the above rules, reinforcing the network’s security posture.
MANAGEMENT Interface Rules
Management Specific Rules Allow
- These are general rules that allow MANAGEMENT subnets to web browse, access the firewall, DNS, and time synchronization.
Management TO * Block
- Acts as a catch-all to deny any traffic not explicitly allowed by the above rules, reinforcing the network’s security posture.
PENTEST Interface Rules
Allow PENTEST to DNS:
- This rule allows PENTEST subnets to resolve domain names, essential for various testing scenarios.
Allow PENTEST to NTP:
- Allows devices to synchronize their time with network time protocol servers.
Allow PENTEST to VULN:
- Enables traffic from penetration testing machines to the vulnerable machines for testing purposes.
PENTEST to AD Rules:
- Set of rules that permit specific AD-related traffic from the PENTEST network to the domain controllers. This ensures that pentesting tools can interact with AD services.
Default Block Rule:
- Acts as a catch-all to deny any traffic not explicitly allowed by the above rules, reinforcing the network’s security posture.
VULN Interface Rules
Allow VULN to NTP:
- Ensures that all devices on the VULN network can synchronize their time, which is critical for logging and correlation.
Allow VULN to PENTEST:
- Allows devices on the VULN network to communicate with the PENTEST network. This is crucial for conducting penetration tests.
Default Block All:
- Acts as a catch-all to deny any traffic not explicitly allowed by the above rules, reinforcing the network’s security posture.
The rules set for each of these interfaces are designed to provide only the necessary levels of access required for their operation, adhering to the principle of least privilege. By controlling traffic in this manner, we minimize potential attack surfaces and maintain a secure and efficient network environment suitable for an enterprise-level homelab.
As we delve into the complexities of firewall configurations, I’d like to remind readers that while I hold a BA degree in network security, I do not consider myself an advanced expert in firewall rules. The configurations I present are based on comprehensive study and hands-on practice within my homelab environment, attempting to align with foundational security principles and a proactive learning approach.
I welcome feedback, insights, and questions from fellow enthusiasts and professionals alike. Together, we can build upon these foundations, share knowledge, and improve our collective understanding of network security practices.
In the next post will go over Active Directory Setup (coming soon).