This project documents the network security and firewall configuration work performed within my physical cybersecurity homelab using pfSense.
The goal of the project was to gain hands-on experience with firewall administration, network traffic control, DHCP management, host aliases, packet analysis, security rule validation, and network troubleshooting.
I deployed pfSense on a dedicated Dell OptiPlex 3040 and configured it to operate as the firewall, router, DHCP server, and default gateway for the homelab. An 8-port unmanaged Ethernet switch connects the physical systems, while a Proxmox server hosts several virtual machines used for Windows, Linux, security monitoring, and controlled offensive security testing.
During the project, I configured DHCP reservations and host aliases, created and tested firewall rules, analyzed network traffic using pfSense packet capture, and restricted external network access for an intentionally vulnerable Metasploitable 2 system.
One of the most important parts of the project involved validating firewall rules rather than assuming they were working as intended. Testing revealed that systems located on the same subnet communicated directly through the Layer 2 switch and therefore did not traverse pfSense. This demonstrated the limitations of firewall enforcement within a flat network and helped identify VLAN-based network segmentation as a future improvement.
The primary objectives of this project were to:
- Deploy and configure pfSense as a dedicated firewall and router.
- Configure predictable addressing using DHCP reservations.
- Create host aliases to simplify firewall administration.
- Build and test firewall rules.
- Analyze traffic using pfSense packet capture.
- Understand how firewall rule ordering affects traffic.
- Validate security controls through connectivity testing, SSH, and Nmap.
- Restrict external network access from an intentionally vulnerable system.
- Analyze blocked traffic through pfSense firewall logs.
- Understand the difference between switched and routed traffic.
- Identify limitations of a flat network architecture.
By the end of the project, I successfully:
- Deployed pfSense as the firewall, router, DHCP server, and default gateway for my cybersecurity homelab.
- Configured DHCP reservations and host aliases for consistent network administration.
- Created and tested firewall policies.
- Used packet capture to analyze how traffic moved through the network.
- Identified why same-subnet traffic bypassed pfSense firewall enforcement.
- Used Nmap and SSH to validate network accessibility.
- Restricted Metasploitable 2 from accessing external networks through pfSense.
- Verified blocked traffic through pfSense firewall logs.
- Identified VLAN-based network segmentation as a future improvement to the lab architecture.
This project was performed within my physical cybersecurity homelab.
| Platform / System | Role | IP Address |
|---|---|---|
| pfSense | Firewall / Router / DHCP / Default Gateway | 192.168.1.1 |
| Proxmox VE | Virtualization Host | 192.168.1.10 |
| Windows 11 Mainlab | Management Workstation | 192.168.1.11 |
| Kali Linux | Security Testing Workstation | 192.168.1.20 |
| Ubuntu Server | Wazuh Server | 192.168.1.30 |
| Ubuntu Desktop | Linux Workstation | 192.168.1.31 |
| Metasploitable 2 | Vulnerable Testing Target | 192.168.1.40 |
| Windows 10 | Domain-Joined Endpoint | 192.168.1.50 |
| Windows Server 2022 | Domain Controller / DNS | 192.168.1.60 |
The physical systems are connected through an 8-port unmanaged Ethernet switch. pfSense provides routing between the lab network and external networks and serves as the default gateway for the lab systems.
The lab currently uses a flat 192.168.1.0/24 network.
The physical network is structured as follows:
Internet
|
pfSense
Dell OptiPlex 3040
|
8-Port Unmanaged Switch
|
+-- Windows 11 Mainlab
|
+-- Kali Linux
|
+-- Proxmox VE
|
+-- Windows Server 2022
+-- Windows 10
+-- Ubuntu Server
+-- Ubuntu Desktop
+-- Metasploitable 2
The Windows 11 system serves as the primary management workstation, while the physical Kali Linux system is used for security testing and network reconnaissance.
The Proxmox server hosts the majority of the virtual systems used throughout the lab.
Network limitation: Because the current switch is unmanaged and the systems reside on the same Layer 2 network, traffic between same-subnet hosts can communicate directly through the switch without traversing pfSense. VLAN-based segmentation is planned as a future improvement.
pfSense was installed on a dedicated Dell OptiPlex 3040 to provide firewall and routing services for the homelab.
During the initial deployment, I encountered a hardware compatibility issue with the first network interface card I purchased. The NIC was not properly supported by pfSense.
After troubleshooting the issue and researching hardware compatibility, I replaced the NIC with compatible hardware and successfully completed the firewall installation.
The pfSense system now functions as the:
- Firewall
- Router
- Default gateway
- DHCP server
- Traffic filtering point
- Network monitoring point
This process provided hands-on experience with firewall deployment, hardware compatibility troubleshooting, network interface configuration, and physical network design.
Before making additional firewall changes, I created a backup of the pfSense configuration. This provided a recovery point in case a configuration change caused connectivity or firewall issues.
pfSense configuration backup interface used to create a recovery point before making additional firewall changes.
To make firewall administration and security testing more predictable, I configured DHCP reservations for systems within the lab.
This allows important systems to consistently receive known IP addresses while their addressing is centrally managed through pfSense.
Examples include:
- Proxmox —
192.168.1.10 - Mainlab —
192.168.1.11 - Kali —
192.168.1.20 - Ubuntu Server —
192.168.1.30 - Ubuntu Desktop —
192.168.1.31 - Metasploitable 2 —
192.168.1.40 - Windows 10 —
192.168.1.50 - Windows Server 2022 —
192.168.1.60
Using predictable addresses makes firewall rules, packet captures, security testing, and troubleshooting easier to manage.
DHCP reservations configured in pfSense to provide predictable addressing for systems within the homelab.
I created pfSense host aliases for important systems within the lab.
Aliases allow firewall policies to reference descriptive names instead of relying entirely on IP addresses.
Aliases created include:
ProxmoxMainlabKaliUbuntu_ServerUbuntu_VMMeta_2Wins10Wins22_Server
For example, a firewall rule can reference Meta_2 rather than directly entering 192.168.1.40.
This makes firewall policies easier to read, understand, and maintain.
Host aliases created in pfSense to simplify firewall rule creation and administration.
The initial LAN configuration used a broad rule allowing LAN systems to communicate while the environment was being built and tested.
The initial policy was:
| Setting | Value |
|---|---|
| Action | Pass |
| Protocol | Any |
| Source | LAN network |
| Destination | Any |
This established basic connectivity before additional security controls were introduced.
I then began creating more specific firewall rules and testing whether the controls behaved as expected.
This process demonstrated the importance of firewall rule ordering. Because pfSense evaluates interface rules in order, a specific block rule must be evaluated before a broader allow rule when both could match the same traffic.
One of the first security policies I attempted to implement was restricting SSH access to the Proxmox server.
The intended policy was:
- Allow Mainlab to SSH into Proxmox.
- Block other systems from SSHing into Proxmox.
The rules were created using the previously configured host aliases.
However, instead of assuming the rules were functioning correctly, I tested the security control.
Testing showed that both Mainlab and Kali could still reach the Proxmox SSH service.
From Kali, I also performed an Nmap scan:
nmap -p 22 192.168.1.10The scan confirmed that the SSH service remained reachable:
PORT STATE SERVICE
22/tcp open ssh
I also successfully established an SSH connection from Kali to Proxmox.
SSH and Nmap testing from Kali confirmed that the Proxmox SSH service remained reachable despite the intended pfSense LAN restrictions, leading to further investigation of same-subnet traffic behavior.
I used the built-in pfSense packet capture functionality to investigate why the SSH firewall rules were not controlling access as expected.
Mainlab and Proxmox are both located on the 192.168.1.0/24 network.
When an SSH connection was established between:
Mainlab: 192.168.1.11
Proxmox: 192.168.1.10
the expected SSH traffic was not observed traversing pfSense.
The reason is that both systems are on the same Layer 2 network.
Instead of sending the traffic to the default gateway, the systems can communicate directly through the Ethernet switch.
The traffic path is effectively:
Mainlab
|
v
Ethernet Switch
|
v
Proxmox
Because pfSense is not in this traffic path, its LAN firewall rules cannot enforce the intended SSH restriction between these same-subnet systems.
I then performed another packet capture to compare same-subnet communication with routed Internet traffic.
From Mainlab, I generated ICMP traffic to:
8.8.8.8
Unlike Proxmox, 8.8.8.8 is outside the local subnet.
Mainlab therefore sends this traffic to its default gateway, causing the traffic to traverse pfSense.
pfSense packet capture showing ICMP echo requests from Mainlab (192.168.1.11) to 8.8.8.8 and the corresponding replies, confirming that Internet-bound traffic traverses the firewall.
The traffic path becomes:
Mainlab
|
v
Ethernet Switch
|
v
pfSense
|
v
Internet
|
v
8.8.8.8
This comparison helped demonstrate the difference between Layer 2 switched traffic and Layer 3 routed traffic.
The SSH testing demonstrated an important limitation in the original firewall design.
The rules represented the intended security policy, but the current network architecture prevented pfSense from enforcing that policy between systems on the same subnet.
After validating this behavior through SSH testing, Nmap, and packet analysis, I disabled the ineffective SSH rules rather than leaving security controls enabled that were not providing their intended protection.
Final pfSense LAN rules showing the active Metasploitable 2 traffic restriction and the disabled Proxmox SSH rules after testing demonstrated that same-subnet traffic bypassed the firewall.
This exercise reinforced the importance of validating security controls rather than assuming that a rule is effective simply because it has been configured.
It also demonstrated why network segmentation becomes important when firewall enforcement is required between different groups of systems.
Metasploitable 2 is an intentionally vulnerable operating system used as a controlled target for security testing within the homelab.
Because the system is intentionally vulnerable, I wanted to prevent it from reaching external networks while preserving its availability as an internal testing target.
Before implementing the restriction, I established a connectivity baseline.
Metasploitable 2 was able to:
- Reach the pfSense gateway.
- Reach external Internet addresses.
- Communicate with Kali.
- Communicate with other systems on the local LAN.
I then created a pfSense firewall rule for Metasploitable 2.
The policy was configured as:
| Setting | Value |
|---|---|
| Action | Block |
| Address Family | IPv4 |
| Protocol | Any |
| Source | Meta_2 / 192.168.1.40 |
| Destination | Any |
| Logging | Enabled |
The block rule was positioned above the general LAN allow rule so that traffic matching the Meta2 rule would be evaluated first.
After applying the firewall rule, I repeated connectivity testing from Metasploitable 2.
I attempted to reach an external address:
ping -c 4 8.8.8.8Result: Blocked
I also tested the pfSense LAN address:
ping -c 4 192.168.1.1Result: Blocked
I tested communication with systems on the same LAN.
Kali: Successful
Proxmox: Successful
These results were consistent with the earlier packet analysis.
Traffic from Metasploitable 2 that must traverse pfSense is subject to the firewall rule and can be blocked.
Communication with same-subnet systems can still occur directly through the Layer 2 switch without traversing pfSense.
Logging was enabled on the Metasploitable 2 block rule so I could verify that pfSense was responsible for dropping the traffic.
The firewall logs showed blocked ICMP traffic originating from:
192.168.1.40
and destined for:
8.8.8.8
The entries were associated with the:
Block Meta2 Internet Access
firewall rule.
pfSense firewall logs confirming that the Block Meta2 Internet Access rule matched and blocked ICMP traffic from Metasploitable 2 (192.168.1.40) to the external address 8.8.8.8.
This provided direct evidence that the firewall policy was being matched and enforced.
The validation process followed:
Establish Baseline
|
v
Create Security Control
|
v
Apply Firewall Rule
|
v
Generate Test Traffic
|
v
Observe Connectivity
|
v
Review Firewall Logs
|
v
Validate Control
The first network interface card purchased for the pfSense system was not properly supported.
I researched the compatibility issue, replaced the NIC with supported hardware, and successfully completed the pfSense deployment.
While configuring firewall policies, I learned how rule order affects traffic evaluation.
Specific security controls must be positioned appropriately relative to broader allow rules to ensure the intended policy is applied.
I initially expected pfSense to control SSH traffic between systems on the LAN.
Testing demonstrated that same-subnet systems communicate directly through the Layer 2 switch rather than routing that traffic through pfSense.
Packet analysis helped identify why the intended SSH restriction was ineffective.
Instead of leaving the ineffective rules enabled, I disabled them and documented network segmentation as a future improvement.
This project reinforced several important networking and cybersecurity concepts:
- Firewall rules should be tested after implementation.
- A configured security control does not automatically mean the control is effective.
- Firewall rule order can affect policy enforcement.
- Devices on the same subnet can communicate without sending traffic through their default gateway.
- Layer 2 switching and Layer 3 routing affect where firewall controls can be enforced.
- Packet captures can help explain unexpected network behavior.
- Firewall logs provide evidence that security policies are being triggered.
- Predictable addressing simplifies firewall administration and security testing.
- Intentionally vulnerable systems should have external network access restricted when possible.
- Network architecture directly affects security policy enforcement.
Through this project, I gained hands-on experience with:
- pfSense administration
- Firewall configuration
- Firewall rule creation and ordering
- DHCP reservations
- Host aliases
- Routing and default gateways
- TCP/IP networking
- Layer 2 switching
- Layer 3 routing
- Packet capture
- Traffic analysis
- Firewall log analysis
- ICMP testing
- SSH
- Nmap
- Kali Linux
- Metasploitable 2
- Network troubleshooting
- Security control validation
- Hardware compatibility troubleshooting
The primary future improvement for this lab is implementing network segmentation.
The current 8-port switch is unmanaged, which prevents me from implementing VLAN-based security zones using the existing switching hardware.
A future upgrade to a VLAN-capable managed switch would allow the environment to be separated into networks such as:
- Management
- Servers
- Client systems
- Security testing
- Vulnerable targets
pfSense could then route traffic between these networks and enforce policies such as:
- Only the management workstation can SSH into Proxmox.
- Kali can initiate security testing against designated targets.
- Client systems cannot initiate connections to the Kali testing network.
- Metasploitable 2 is isolated from trusted systems and external networks.
- Management services are restricted to authorized systems.
This would extend the current project from firewall configuration and traffic-control testing into a segmented network architecture with inter-VLAN firewall enforcement.
This project is part of a larger cybersecurity homelab used for hands-on networking, system administration, offensive security, and defensive security practice.
Related projects include:
- Cybersecurity Homelab
- Active Directory Security Lab
- Wazuh Detection Engineering Lab