This guide provides step-by-step instructions for completing all 12 System & Communications Protection labs. Each lab presents a real-world network security challenge using the pfSense firewall — the same technology used by thousands of organizations to protect their networks.
In these labs you will use pfSense — an open-source firewall and router platform — to configure boundary protection, create deny-by-default policies, segment networks, audit firewall rules, and investigate logs. These are the same skills a network security analyst uses daily.
These labs align with CMMC Level 1 System & Communications Protection (SC) requirements:
This single SC control covers boundary protection, firewall configuration, network segmentation, deny-by-default policies, and communications monitoring.
You will connect to the lab through Apache Guacamole — a web-based remote desktop gateway. There is nothing to install; everything runs in your web browser.
student01student02student05student12After logging in, you will see a list of available connections:
| Connection Name | What It Is |
|---|---|
| PODXX-SRV | Your own pod member server — your desktop for every lab, including the firewall labs |
The pfSense firewall is not a separate connection. You reach it from a browser
inside PODXX-SRV, as described in the next section.
Tip: To return to the Guacamole home screen, press Ctrl+Alt+Shift to open the side menu, then click Home.
Most SC labs require you to log into the pfSense firewall web interface. Do it
from inside your remote desktop:
http://10.51.1.1http://10.51.5.1http://10.51.12.1| Field | Value |
|---|---|
| Username | the firewall username your instructor gave you |
| Password | the firewall password your instructor gave you |
Firewall credentials are issued by your instructor and are not published on this
wiki. They are printed in your handout.
After logging in, you will see the pfSense Dashboard showing system status, interfaces, and traffic information.
Lab artifacts (worksheets, instructions, evidence templates) are stored on the Domain Controller:
C:\CyberLab\PodXX\SC-Artifacts\SC-M1-L1_* — Module 1, Lab 1 filesSC-M1-L2_* — Module 1, Lab 2 files_LAB_READY_SC-M1-L1.txt — Marker indicating lab is seededAfter completing each lab, save your evidence to the same SC-Artifacts directory:
Each student has an isolated pod environment:
Your Pod (PodXX)
├── PODXX-SRV (your pod member server, joined to acs-p01.local)
│ ├── AD tools (ADUC, GPMC, AD PowerShell) bound to DC01-P01 / DC02-P01
│ ├── Lab artifacts: C:\CyberLab\PodXX\SC-Artifacts\
│ └── Shared with AC, IA, SI labs
│
└── PODXX-GW (Gateway/Firewall — reached from a browser on PODXX-SRV)
├── WAN Interface: Connected to external network
├── LAN Interface: 10.51.XX.1/24
├── Web UI: http://10.51.XX.1
└── SSH: admin@10.51.XX.1
Your firewall is completely isolated from other students' pods. You can make any configuration changes without affecting anyone else.
Difficulty: Beginner | Time: 20 minutes | Type: Document-based
You are the new cybersecurity analyst at ACS Consulting, a small defense contractor. Your first task is to identify the trust boundaries in the company's network.
SC-M1-L1_Boundary_Worksheet.txtSC-M1-L1_Network_Topology.txtOpen the Network Topology reference:
C:\CyberLab\PodXX\SC-Artifacts\SC-M1-L1_Network_Topology.txtLog into pfSense to see the live configuration:
http://10.51.XX.1Open the Boundary Worksheet:
SC-M1-L1_Boundary_Worksheet.txtTask 1 — Identify the External Boundary:
Task 2 — Identify the Internal Boundary:
Task 3 — Mark Trusted vs Untrusted Assets:
Task 4 — Locate where FCI should reside:
Save your completed worksheet:
Save as: C:\CyberLab\PodXX\SC-Artifacts\SC-M1-L1_Completed.txt
This exact file name is required (
.txt,.csv, or.pngis accepted) and it must contain at least 50 characters of content.
CMMC SC.L1-3.13.1 requires organizations to identify and protect their system boundaries. Without knowing where your boundaries are, you cannot protect them.
Difficulty: Beginner | Time: 30 minutes | Type: Hands-on (pfSense)
The pfSense firewall currently has an "Allow Any Any" rule — it permits ALL traffic through without restrictions. This is a critical security misconfiguration that violates CMMC deny-by-default requirements.
SC-M1-L2_Lab_Instructions.txtLog into pfSense:
http://10.51.XX.1View the current (bad) rules:
Understand the problem:
Delete the "Allow Any Any" rule:
Create specific allow rules (deny-by-default):
Rule 1: Allow DNS
10.50.1.10Allow DNS to DC01Rule 2: Allow Web Traffic
Allow web browsingRule 3: Allow ICMP (Ping)
Allow ping for troubleshootingVerify the default deny is in place:
Click Apply Changes
Test your configuration:
10.50.1.10 (DC01) — should succeedSave evidence:
Save as: C:\CyberLab\PodXX\SC-Artifacts\M1-L2_FinalRules.png
Hint: If you accidentally lock yourself out of the pfSense web UI, don't panic. The anti-lockout rule at the top prevents this. If it does happen, ask your instructor for help.
"Deny by default" is the foundation of all network security. Instead of trying to block everything bad (impossible), you only allow what is specifically needed. This is required by CMMC SC.L1-3.13.1.
Difficulty: Intermediate | Time: 30 minutes | Type: Hands-on (pfSense)
A firewall has three core responsibilities: Monitor (observe and log traffic), Control (decide what traffic is allowed), and Protect (block harmful traffic). Your firewall has rules demonstrating all three. Your job is to identify which is which.
SC-M1-L3_Worksheet.txtLog into pfSense and go to Firewall → Rules → LAN
Review each rule and identify its responsibility:
| Rule Description | Responsibility | Why? |
|---|---|---|
| Web traffic (logging enabled) | Monitor | Logging shows us what's happening |
| DNS only to DC01 | Control | Restricts DNS to a specific server |
| Block access to management network | Protect | Prevents unauthorized access |
| Default Deny | Protect | Blocks everything not explicitly allowed |
Check the logs to see monitoring in action:
Complete the worksheet:
SC-M1-L3_Worksheet.txt on the DCSave evidence:
Save as: C:\CyberLab\PodXX\SC-Artifacts\M1-L3_Worksheet_Complete.txt
Understanding Monitor/Control/Protect helps you design complete security architectures. A firewall that only blocks (protects) but doesn't log (monitor) is blind to attacks. One that only logs but doesn't restrict (control) is useless.
Difficulty: Beginner | Time: 20 minutes | Type: Document-based
Using your pod's live pfSense configuration, create a complete organizational boundary diagram showing all network zones, connections, and security boundaries.
Gather network information from pfSense:
Open the boundary worksheet on the DC:
SC-M2-L1_Boundary_Worksheet.txtDraw your diagram including:
Save your completed diagram:
Save as: C:\CyberLab\PodXX\SC-Artifacts\SC-M2-L1_Completed.txt
This exact file name is required (
.txt,.csv, or.pngis accepted) and it must contain at least 50 characters of content.
Difficulty: Advanced | Time: 45 minutes | Type: Hands-on (pfSense)
ACS Consulting's public web server is sitting on the internal LAN at 10.51.XX.50. This means external visitors accessing the web server can potentially reach internal resources like DC01. You must move the web server into a DMZ (Demilitarized Zone).
Log into pfSense and review the current (bad) configuration:
Create a DMZ interface:
Your firewall has only two physical ports (WAN and LAN), so Interfaces →
Assignments has no + Add button until you create a VLAN for the DMZ to
sit on. Do it in this order:
vtnet1 (LAN)50DMZVLAN 50 on vtnet1 interface (it appears as OPT1)DMZ10.52.XX.1 / 24 (replace XX with your pod number)The DMZ must use a subnet of its own. Do not give it an address inside
10.51.XX.0/24— that range already belongs to the LAN and pfSense will
reject the overlap.
Update firewall rules:
DMZ rules:
LAN rules:
Update NAT rules:
Verify:
Save evidence:
Save as: C:\CyberLab\PodXX\SC-Artifacts\M2-L2_DMZ_Rules.png
Save as: C:\CyberLab\PodXX\SC-Artifacts\M2-L2_DMZ_Verification.txt
Hint: The key concept is that a DMZ is a "semi-trusted" zone. External users can reach the web server, but if the web server is compromised, the attacker cannot reach the internal LAN.
How the automated check scores this lab: it passes as soon as the firewall
has an assigned optional interface (the DMZ you added in step 2). The rules, NAT
change and verification evidence are graded by your instructor.
Difficulty: Advanced | Time: 45 minutes | Type: Hands-on (pfSense)
ACS Consulting has four departments on a flat network — HR, Finance, Engineering, and Guest WiFi. Any device can reach any other device. A guest on the WiFi can access HR file shares and Finance databases.
Review the segmentation plan:
SC-M2-L3_Segmentation_Plan.txt on the DCCreate VLANs on pfSense:
vtnet1 (LAN)10HR DepartmentAssign VLAN interfaces:
Go to Interfaces → Assignments (the + Add button only appears once
at least one VLAN exists)
Assign each VLAN as a new interface (OPT1 through OPT4)
Rename them: HR, FINANCE, ENGINEERING, GUEST
Set each interface to Static IPv4 with its own subnet — replace XX with
your pod number:
| Interface | VLAN | IPv4 address |
|---|---|---|
| HR | 10 | 10.61.XX.1/24 |
| FINANCE | 20 | 10.62.XX.1/24 |
| ENGINEERING | 30 | 10.63.XX.1/24 |
| GUEST | 40 | 10.64.XX.1/24 |
Enable each interface → Save → Apply
Do not give a VLAN an address inside
10.51.XX.0/24; that range belongs to
the LAN and pfSense rejects the overlap.
Configure DHCP (optional):
Create firewall rules for isolation:
HR VLAN rules:
Finance VLAN rules:
Guest VLAN rules:
Verify isolation:
Save evidence:
Save as: C:\CyberLab\PodXX\SC-Artifacts\M2-L3_VLAN_Config.png
Save as: C:\CyberLab\PodXX\SC-Artifacts\M2-L3_Isolation_Test.txt
How the automated check scores this lab: it passes when two or more VLANs
exist on the firewall. The isolation rules and test evidence are graded by your
instructor.
Network segmentation limits the blast radius of a breach. If an attacker compromises a guest device, they cannot reach HR or Finance data. This is a core CMMC SC requirement.
Difficulty: Intermediate | Time: 30 minutes | Type: Hands-on (pfSense)
A previous administrator left messy, insecure firewall rules. You must audit every rule, identify issues, clean up the rule set, and verify everything still works.
Log into pfSense and go to Firewall → Rules → LAN
Open the audit worksheet:
SC-M3-L1_Audit_Worksheet.txtAudit each rule — identify the issue type:
| Issue Type | Description | Example |
|---|---|---|
| [A] Allow Any | Overly permissive rule | "Allow ALL traffic" |
| [S] Shadowed | Never fires because a broader rule above matches first | A block rule after an allow-all |
| [D] Duplicate | Same effect as another rule | Two identical allow rules |
| [U] Unused | References a network/service that doesn't exist | Blocking a nonexistent subnet |
| [O] OK | Legitimate, properly scoped | "Allow DNS to DC01" |
Document each rule in the audit table
Clean up the rules:
Verify connectivity:
Save evidence:
Save as: C:\CyberLab\PodXX\SC-Artifacts\M3-L1_Audit_Complete.txt
Save as: C:\CyberLab\PodXX\SC-Artifacts\M3-L1_CleanRules.png
How the automated check scores this lab: it objects to a pass rule of any to
any with no protocol, and to two identical rules on the same interface tab
(same action, protocol, source and destination). Duplicates are judged per
interface, so the separate default-deny rule each interface needs after M2-L2 and
M2-L3 is not counted as a copy of another tab's deny. A failure reads
FAIL:Issues(N) followed by the rule it objected to — N is how many rules it
objected to, not a task number.
Difficulty: Intermediate | Time: 25 minutes | Type: Hands-on (pfSense)
The firewall has all the right rules, but they are in the wrong order. A "Block All" rule appears BEFORE the allow rules, so all legitimate traffic is being blocked.
Log into pfSense and go to Firewall → Rules → LAN
Observe the problem:
Reorder the rules:
Click Apply Changes
Verify everything works:
Save evidence:
Save as: C:\CyberLab\PodXX\SC-Artifacts\M3-L2_Reordered_Rules.png
Key Takeaway: In firewall administration, the ORDER of rules is as important as the rules themselves. A correctly written rule in the wrong position is useless.
How the automated check scores this lab: only the LAN tab is examined.
It passes when the LAN tab has at least one allow rule and the last LAN rule is
a block rule to any destination. The deny rule may have a source of LAN net
or any — either is accepted, so this lab and M3-L1 (which is about removing
overly broad and duplicate allow rules) cannot contradict each other. Rules on
the WAN, DMZ or VLAN tabs do not affect this lab.
Difficulty: Intermediate | Time: 25 minutes | Type: Hands-on (pfSense)
The accounting application at 10.51.XX.100 only needs HTTPS (TCP 443). But the firewall allows FTP, SSH, Telnet, HTTP, MySQL, and an alternate HTTP port — all unnecessary and potentially dangerous.
Log into pfSense and go to Firewall → Rules → LAN
Identify rules targeting the accounting server (10.51.XX.100):
Delete unnecessary port rules:
Verify:
Save evidence:
Save as: C:\CyberLab\PodXX\SC-Artifacts\M3-L3_LeastPrivilege_Rules.png
Least privilege means giving only the minimum access needed. An application that only needs port 443 should not have ports 21, 22, 23, 80, 3306, and 8080 open. Each open port is an attack surface.
How the automated check scores this lab: it looks for exactly one pass rule whose
destination is the host 10.51.XX.100 on port 443 (443, HTTPS and 443-443
all count, and .100/32 is accepted), on any interface tab. FAIL:ExtraPorts(N)
lists the unnecessary ports still open; FAIL:NoHTTPSRuleTo10.51.XX.100 means the
keeper rule is gone — usually all seven rules were deleted, or the survivor points at
an interface or network address instead of the host, or its protocol is UDP.
Difficulty: Intermediate | Time: 30 minutes | Type: Hands-on (pfSense)
Your firewall logs contain evidence of suspicious activity. As the security analyst, investigate the logs and document your findings.
Log into pfSense and go to Status → System Logs → Firewall
Investigate the following categories:
Port Scans:
Blocked Malware Indicators:
Denied Legitimate Traffic:
Suspicious Sources:
Open the investigation worksheet on the DC:
SC-M4-L1_Investigation_Worksheet.txtSave evidence:
Save as: C:\CyberLab\PodXX\SC-Artifacts\SC-M4-L1_Completed.txt
This exact file name is required (
.txtor.csv) and it must contain at least 50 characters of content.
Difficulty: Intermediate | Time: 35 minutes | Type: Hands-on (pfSense + DC)
You are performing a simplified CMMC assessor walkthrough. Using the compliance checklist, verify that your pod's System & Communications Protection controls are properly implemented.
Open the compliance checklist on the DC:
SC-M4-L2_Compliance_Checklist.txtWork through each section:
Boundary Protection:
Firewall Configuration:
Logging:
Segmentation:
FCI Protection:
For each checklist item:
Save evidence:
Save your completed checklist to: C:\CyberLab\PodXX\SC-Artifacts\SC-M4-L2_Completed.txt
Save any screenshots to: C:\CyberLab\PodXX\SC-Artifacts\M4-L2_Compliance_Evidence\
SC-M4-L2_Completed.txt(or.csv) is the file verification looks for, and it must contain at least 50 characters of content. Screenshots are supporting evidence only.
Difficulty: Expert | Time: 60 minutes | Type: Hands-on (pfSense + DC)
ACS Consulting, a small defense contractor, has inherited a poorly configured network. The firewall allows all traffic, has no segmentation, no logging, and dangerous services are exposed to the internet. You must fix EVERYTHING.
This lab is the practical assessment for the entire SC module. You will use everything you have learned.
Log into pfSense and assess the damage:
TASK 1: Implement Deny-By-Default (15 min)
TASK 2: Secure the WAN (10 min)
TASK 3: Create Network Segmentation (15 min)
TASK 4: Enable Logging (5 min)
TASK 5: Verify Communications (10 min)
TASK 6: Produce Assessment Evidence (5 min)
Save all evidence:
Save to: C:\CyberLab\PodXX\SC-Artifacts\M4-L3_Capstone\
All 6 tasks must be completed with evidence:
How the automated check scores this lab: the verifier reads the firewall
configuration and reports 5 checks — deny_by_default, wan_secured,
no_telnet, logging (the Log packets box ticked on every block rule) and
segmentation (2 or more VLANs). Task 5 and Task 6 are graded from your saved
evidence by your instructor, not by the automated check, so "5 of 5" is a full
pass. If the tracker shows fewer than 5, it names the failing check, and for logging
it names every block rule still missing the tick:
capstone: passed 4/5 checks; failing: logging
(logging off on rule 10 on opt1 ('Block DMZ to LAN lateral movement'))
no block rules exist yet instead means Task 1's default deny has not been created.
| Task | Where to Go |
|---|---|
| View/edit firewall rules | Firewall → Rules (select interface: LAN, WAN, etc.) |
| Create a new rule | Firewall → Rules → + Add |
| View firewall logs | Status → System Logs → Firewall |
| View system dashboard | Status → Dashboard |
| View interface status | Status → Interfaces |
| Create VLANs | Interfaces → VLANs |
| Assign interfaces | Interfaces → Assignments |
| Configure NAT/port forwarding | Firewall → NAT → Port Forward |
| Test connectivity (ping) | Diagnostics → Ping |
| Configure DHCP | Services → DHCP Server |
| View ARP table | Diagnostics → ARP Table |
| Backup configuration | Diagnostics → Backup & Restore |
| Mistake | Solution |
|---|---|
| Forgetting to click "Apply Changes" | Always click the yellow "Apply Changes" bar at the top after modifying rules |
| Creating rules on wrong interface | LAN rules = traffic FROM LAN devices. WAN rules = traffic FROM the internet |
| Deleting the anti-lockout rule | Don't delete it — it keeps you from locking yourself out of the web UI |
| Rules in wrong order | Default deny must always be LAST. Specific rules go first |
| Not saving evidence | Screenshot every change before and after |
http://10.51.XX.1Use this checklist to track your progress:
| Lab | Name | Status |
|---|---|---|
| M1-L1 | Understanding Trust Boundaries | ☐ |
| M1-L2 | Deny By Default Firewall | ☐ |
| M1-L3 | Monitor, Control, Protect | ☐ |
| M2-L1 | Draw Organizational Boundary | ☐ |
| M2-L2 | Secure the DMZ | ☐ |
| M2-L3 | Internal Segmentation (VLANs) | ☐ |
| M3-L1 | Firewall Rule Audit | ☐ |
| M3-L2 | Rule Ordering Challenge | ☐ |
| M3-L3 | Least Privilege Access | ☐ |
| M4-L1 | Firewall Log Investigation | ☐ |
| M4-L2 | Verify SC Compliance | ☐ |
| M4-L3 | Final Capstone | ☐ |
After completing each lab:
C:\CyberLab\PodXX\SC-Artifacts\This guide was created for the Digital Resilience Community Clinic (DRCC) Cyber Range.
CMMC Level 1 — System & Communications Protection (SC) Module