This project simulates a small-business network secured and segmented by a pfSense firewall running in Microsoft Hyper-V. The environment separates corporate and guest devices into independent IPv4 subnets while providing controlled internet access through the WAN interface.
The lab demonstrates practical network administration, firewall rule design, DHCP configuration, NAT, troubleshooting, traffic validation, and security logging. The final result allows corporate systems to use the protected LAN while guest systems can access the internet but cannot reach corporate resources or the pfSense management portal.
- Deploy pfSense Community Edition as a virtual firewall in Hyper-V.
- Build separate WAN, corporate, and guest network segments.
- Configure static gateway addresses and DHCP scopes for both internal networks.
- Provide internet connectivity through outbound NAT.
- Prevent guest devices from accessing corporate resources.
- Prevent guest devices from opening the pfSense web interface.
- Verify permitted and denied traffic with PowerShell and pfSense logs.
- Document the environment as a repeatable portfolio project.
| Technology | Purpose |
|---|---|
| pfSense CE 2.8.1 | Routing, firewalling, DHCP, DNS forwarding, NAT, and logging |
| Microsoft Hyper-V | Virtual machines and isolated virtual switches |
| Windows 11 Pro | Host system and network validation workstation |
| PowerShell | Interface management and connectivity testing |
| IPv4 and subnetting | Addressing and separation of network zones |
| DHCP and DNS | Automatic client configuration and name resolution |
| Stateful firewall rules | Enforcement of corporate and guest access policies |
flowchart TD
Internet["Internet / Upstream Network"] --> WAN["WAN-EXTERNAL"]
WAN --> FW["pfSense Firewall"]
FW --> CORP["CORP-LAN<br/>192.168.10.0/24"]
FW --> GUEST["GUEST-LAN<br/>192.168.20.0/24"]
CORP --> CorpClient["Corporate Client"]
GUEST --> GuestClient["Guest Client"]
pfSense uses three virtual network adapters:
- WAN (hn0): Connected to the external Hyper-V switch and receives an upstream address through DHCP.
- LAN (hn1): Connected to
CORP-LANfor trusted corporate devices. - GUEST (hn2): Connected to
GUEST-LANfor isolated guest devices.
| Zone | Hyper-V switch | Subnet | Gateway | DHCP scope | Access level |
|---|---|---|---|---|---|
| WAN | WAN-EXTERNAL |
Upstream DHCP network | Upstream router | Upstream DHCP | Internet uplink |
| Corporate | CORP-LAN |
192.168.10.0/24 |
192.168.10.1 |
192.168.10.100-199 |
Trusted LAN and internet |
| Guest | GUEST-LAN |
192.168.20.0/24 |
192.168.20.1 |
192.168.20.100-199 |
Internet only |
- Created dedicated Hyper-V switches for WAN, corporate, and guest traffic.
- Deployed a Generation 2 pfSense VM with three network adapters.
- Installed pfSense CE 2.8.1 and assigned
hn0,hn1, andhn2to their respective zones. - Configured the corporate and guest interface addresses.
- Enabled DHCP services for both internal networks.
- Verified the WAN default route and outbound internet connectivity.
- Added ordered guest firewall rules to enforce isolation.
- Tested allowed and denied paths from the guest network.
- Reviewed firewall logs to confirm that blocked traffic was recorded.
- Exported a private configuration backup and completed final validation.
pfSense evaluates interface rules from top to bottom and applies the first matching rule. The guest deny rules therefore appear before the general internet allow rule.
| Order | Action | Source | Destination | Service | Purpose |
|---|---|---|---|---|---|
| 1 | Block | GUEST subnets |
LAN subnets |
Any | Prevent access to the corporate network |
| 2 | Block | GUEST subnets |
GUEST address |
TCP 443 | Prevent access to the pfSense GUI |
| 3 | Pass | GUEST subnets |
Any | Any | Allow guest internet access |
Final tests were performed from the guest network with source address 192.168.20.100.
Test-NetConnection 192.168.10.1 -Port 445
Test-NetConnection 192.168.20.1 -Port 443
Test-NetConnection www.microsoft.com -Port 443| Test | Expected | Result |
|---|---|---|
| Guest to corporate SMB path | Blocked | TcpTestSucceeded: False |
| Guest to pfSense HTTPS portal | Blocked | TcpTestSucceeded: False |
| Guest to internet HTTPS | Allowed | TcpTestSucceeded: True |
These results confirm that the guest network remains isolated while retaining internet access.
The following ten selected screenshots document the project in logical implementation order. The complete set of 12 screenshots is available in the screenshots directory.
Dedicated Hyper-V switches establish separate WAN, corporate, and guest broadcast domains.
The pfSense VM contains three adapters, each connected to the correct virtual switch.
pfSense CE 2.8.1 is installed and the WAN, LAN, and guest interfaces are assigned.
The two internal interfaces use separate /24 networks with their own gateway and DHCP configuration.
The pfSense interface status page confirms that WAN, LAN, and GUEST are operational with the intended addresses.
Ordered rules block guest access to corporate resources and the pfSense GUI before permitting general internet traffic.
Connectivity tests demonstrate that prohibited internal paths fail while permitted internet access succeeds.
The corporate segment is validated for gateway access, DNS resolution, and external connectivity.
Filtered pfSense logs provide evidence that traffic originating from the guest client is evaluated and blocked by the firewall.
The final PowerShell test set records two blocked internal paths and one successful internet path from the guest segment.
The initial WAN connection used the Hyper-V Default Switch. Although pfSense obtained an address and could reach its gateway, internet traffic was unreliable. A dedicated external switch named WAN-EXTERNAL, bound to the physical Wi-Fi adapter, provided a predictable upstream connection.
The Windows host contained several similarly named Hyper-V adapters. Commands initially failed because the interface alias did not exactly match the installed adapter name. Running Get-NetAdapter first exposed the correct aliases and prevented changes from being applied to the wrong network.
A broad pass rule placed above a deny rule would allow the traffic before pfSense reached the restriction. Placing specific blocks first and the general internet rule last produced the intended policy.
Successful ping alone does not prove that an application is reachable. Test-NetConnection was used with specific TCP ports to validate the actual security requirements.
The pfSense configuration backup is intentionally not published because configuration exports can contain internal details and sensitive values. The repository contains screenshots and documentation only.
- Hyper-V virtual networking
- pfSense installation and administration
- IPv4 addressing and subnetting
- DHCP, DNS, routing, and NAT
- Stateful firewall rule design
- Network segmentation and least-privilege access
- PowerShell network diagnostics
- Firewall log review and evidence collection
- Technical documentation and troubleshooting
This lab complements the Active Directory, help desk, Microsoft Entra ID/Intune, and PowerShell automation projects in this portfolio. Together, they demonstrate an end-to-end support environment covering identity, endpoints, ticket operations, automation, and network security.
Carlos Cabrera
CompTIA A+ Certified | IT Support | Windows Administration | Networking