Planning a Segmented Home Network and Cybersecurity Lab
Cybersecurity
1/17/2026
Planning a Segmented Home Network and Cybersecurity Lab
Introduction and Motivation
In two of my earlier articles, I outlined my motivation and guiding principles for migrating from Windows to Linux and how to harden an Ubuntu system. For the last 1.5 years, alongside my main Windows 11 workstation, I have been running a dual‑Linux setup based on Ubuntu (Debian family) and Arch Linux as a long‑term experiment in daily‑driver suitability and security.
Now is the time to plan the next step by consolidating my environment on Ubuntu as the primary Linux platform and phasing out Windows as a regular operating system in my personal workflow.
My second initiative is to build a cybersecurity home lab as a separate subproject. Hence, my project comprises two steps that need to be clearly distinguished from each other:
Migration
Migrating my primary workstation from Windows to Ubuntu for daily use is a substantial change that requires careful, step-by-step planning. The middle section of the architecture diagram in the title image illustrates the target Linux-based home office that this migration is designed to achieve as the first subproject.
Cybersecurity Lab
In 2025, I began a structured journey toward becoming a security analyst. This included completion of the Security Analyst Nanodegree at Udacity, with its strong emphasis on practical, virtualized lab work.
Those exercises based on virtual machines (VMs) were invaluable and secure at the same time, but they also highlighted a compelling aspiration: designing, deploying, and operating a real cybersecurity lab at home to explore security architecture, hardening, and monitoring in a realistic environment.
Building a Home Network Based on Segmentation
Building my own environment forces me to acquire and combine many skills, accept real constraints, and put genuine “skin in the game.” A misconfigured VM functioning as a sandbox can be shut down without consequences. A misconfigured physical lab or a careless malware test can affect the actual network. That difference is why a real, segmented home network and cybersecurity lab are so valuable for learning.
Planning and research are the critical stages of this journey, and any temptation to rush should be resisted. This article therefore focuses on the deliberate planning of the overall setup.
Currently, I am working on my Security Architect Nanodegree at Udacity. So once I gain the proficiency needed to manage this kind of network segmentation, I will actually implement my plans.
The first task is to create an architectural diagram (see title image). For this, I intentionally use an AI-based Large Language Model and then have its output reviewed by a second model for validation.
Incrementally System Building Strategy
Building the home lab will be accomplished by an incremental setup. Purely migrating from Windows to Linux is the starting point, followed by gradually building a cybersecurity lab. The following steps are involved:
- Operating System Migration
- Network Segmentation
- Central Monitoring
- Cybersecurity Lab
Part 1: Operating System Migration
Determining the Hardware Compatibility
The first step is to design the Linux architecture, and specifically the file/backup system. This depends on the underlying hardware and the amount of data to be transferred.
I confirmed that my main PC – an HP Elite 800 G9 – is compatible with Ubuntu 24.04 LTS (Long-Term Support). Ubuntu provides stability and a rich ecosphere of people, applications, and infrastructure.
Storage and Backups
I need to decide where my “source of truth” will live (for example, the HP Elite 800 G9 with its internal 2 TB data disk) and how it will be backed up locally and to external media.
File‑sharing protocols on Linux have two viable options:
- Samba for data that still needs to be accessed from Windows clients
- NFS (Network File System) for high‑performance Linux-to-Linux access between Ubuntu machines
Both can run side by side on the same shares.
Application Inventory and Service Categorization
A list of all applications I use on Windows helps to identify which can be maintained or replaced. I categorize by:
- Native on Linux: browser, SSH, IDEs (such as Visual Studio)
- Web/SaaS: as an OS‑agnostic solution (e.g., webmail, banking, travel booking)
- Windows‑only clients: legacy apps, password manager, specialized software (e.g., Dragon NaturallySpeaking), malware detection, VPN clients
Identity, Authentication, and Email Transition
Critical questions to clarify:
- What identification is in use, and where am I authenticating today: local accounts only, or also Azure AD (Microsoft Entra) / Microsoft 365?
- Are critical credentials (password manager, backup keys, SSH keys) available and pre-tested on Ubuntu?
- What email server type is in use (IMAP/SMTP, Exchange, M365)? Which Linux client (e.g., Thunderbird, Evolution) aligns best with my workflow?
Building the Initial Backup Set
Before migrating from Windows, I will create at least one full backup of:
- User profiles (Documents, Desktop, project folders)
- Email archives (PST/OST, exported mailboxes)
- Password databases
- Photos, recordings, and any other personal data
I store this on an external Seagate drive and verify a test restore on a Linux machine to confirm that the backups are usable.
Hard Cut or Transition Period
Planning will never be perfect. A brief dual‑use period is warranted in which I read and send email from both Windows and Ubuntu to confirm that filters, signatures (S/MIME, PGP), and archives all function correctly.
A dual use on the same device is logistically cumbersome, but better than a complete disk wipe. This needs to be balanced by a second backup to reduce the risk of disk failure or incompatibility.
The second backup disk could also serve the 3‑2‑1 backup philosophy: have 3 copies of files, 2 different media, with one off-site version (disk at a friend’s location, or cloud).
Part 2: Network Segmentation
Virtual LAN
Virtual Local Area Networks (VLANs) make it possible to segregate multiple logical network segments, even when their traffic runs through the same physical Ethernet cables, as long as the devices connect to a switch that supports VLAN configuration. In principle, these broadcast domains remain isolated from each other.
VLANs are a Layer 2 (Data Link) construct in the OSI model, even though they are often deployed in a 1:1 relationship with Layer 3 (Network) IP subnets. Within a VLAN, Ethernet frames are forwarded (including Layer 2 broadcasts) only among ports assigned to that VLAN. So, each VLAN behaves like its own switch, just logically distinct rather than physically.
Subnetting to Reserve IP Ranges for Each VLAN
Subnetting gives each VLAN its own IP range. The idea is to pick one IP block per segment and bind it to the corresponding VLAN interface, for example:
- VLAN 10 – Home Office: 10.10.10.0/24 (hosts 10.10.10.1–10.10.10.254)
- VLAN 20 – Cybersecurity Lab: 10.10.20.0/24 (hosts 10.10.20.1–10.10.20.254)
Cisco Catalyst 1000 Series Switch
The Cisco Catalyst 1000 Series switch is designed for small and medium-sized enterprise networks, branch offices, and smaller businesses. It:
- supports multiple VLANs
- provides SPAN*
- can do some basic Layer 3 static routing between VLAN interfaces
*The Switched Port Analyzer (SPAN) feature on Cisco switches allows mirroring traffic from one or more source ports or VLANs to a destination port for monitoring or analysis of network traffic with Security Onion, Wireshark, Zeek, Suricata, etc.
Limitations of Using VLAN
Policy control at Layer 3 with the Cisco switch is limited. VLANs allow separation at Layer 2 inside the switch (different broadcast domains) and, by default, no inter‑VLAN communication without routing, but relying on this alone is fragile:
- A simple flat uplink from the Catalyst to an ISP router would place both VLANs into the same IP segment upstream, undoing isolation.
- As soon as both VLANs need internet access, a simple “flat” uplink that lands in the same untagged network on the router side effectively collapses isolation at Layer 3 and re‑joins the traffic.
Consequence
Proper segmentation and policy enforcement should rely on a firewall/router upstream.
NetGate 1100 running pfSense Plus
The Netgate 1100 supports the IEEE 802.1Q standard for VLAN tagging on its interfaces. The built-in pfSense software allows per‑VLAN firewall rules, DHCP, DNS, and VPN configuration.
The Netgate firewall is then configured to control exactly how (or if) those VLAN IP ranges can talk to each other or to the internet, enforcing a least‑privilege model, for example:
- “VLAN 20 (Lab) can only reach the internet, not VLAN 10 (Home)”
- “One management workstation in VLAN 10 may SSH into VLAN 20, but no other traffic is allowed”
VLAN 802.1Q VLAN Tagging
With 802.1Q, the Ethernet frame is extended by 4 bytes, adding a VLAN tag inside the frame header:
- The VLAN ID field contains a 12-bit VLAN identifier that is used to separate traffic into VLANs.
- The tag also includes three bits of Priority Code Point (PCP), which can represent 8 priority levels and can be mapped to service classes or a Class of Service (CoS).
Putting the Main Network Components Together
A single trunk from the Netgate 1100 to the Catalyst 1000 carries multiple VLANs (home, IoT, lab, guest) using 802.1Q tags.
On pfSense:
- A virtual interface is created for each VLAN tag.
- Each virtual interface is assigned an IP address (gateway).
- DHCP is enabled for that subnet.
- Devices in VLAN 10 and VLAN 20 always receive addresses from different ranges.
On the Catalyst:
- Access ports for Home are untagged in VLAN 10.
- Lab devices are untagged in VLAN 20.
- The uplink to Netgate is a trunk carrying both VLAN tags.
Because each VLAN has its own subnet and virtual interface on pfSense, the Netgate – acting as a firewall – can enforce “least privilege” rules per segment.
Part 3: Central Monitoring
SIEM
A key design goal of the home network is to observe what happens inside it, not only move packets without understanding traffic patterns.
The architecture includes a central logging and SIEM (Security Information and Event Management) component in the home-office VLAN. Critical systems—the Netgate firewall, the Catalyst switch, the Ubuntu desktop, and the cybersecurity lab hosts—all send their logs to a dedicated collector.
The SIEM system:
- Aggregates syslog events, firewall alerts, and authentication logs.
- Applies correlation rules and dashboards.
This enables use cases such as:
- Spotting port scans against the lab.
- Detecting failed SSH logins on the Ubuntu workstation.
- Identifying unusual connections from IoT devices.
Over time, this central view turns the home lab into a training ground for log analysis, detection engineering, and incident triage—skills that directly support progress toward a security‑architect role.
Benefits of Lab SIEM
- Realistic monitoring practice: In production, security teams centralize logs from all zones into a monitoring platform; mirroring that model in the lab provides realistic experience in correlation, alerting, and incident workflows.
- Controlled exposure: As long as logs are transported over internal, firewall‑controlled paths (e.g., syslog/CEF from VLAN 20 to a SIEM listener in VLAN 10) and not via direct SMB/NFS shares, the SIEM host observes lab activity without participating in it.
- Read-only telemetry: The SIEM receives read‑only telemetry from the lab, requiring only minimum traffic rules (e.g., UDP/TCP 514 for syslog) from VLAN 20 to the SIEM, with everything else blocked.
- Noise management: Lab activity can generate many noisy events (port scans, repeated auth failures); use separate indexes, tags, or dashboards so “lab noise” does not drown out events from the home environment.
Untrusted Guest/ISP Edge
At the outer edge of the design sits the ISP router, which is treated as an untrusted, flat network segment. This device:
- terminates the internet connection,
- provides basic NAT and Wi‑Fi,
- is not part of the security architecture,
- is assumed to receive firmware and configuration changes independently of the lab.
The router segment is used only for low‑trust use cases such as guest devices, kept logically separate from the internal VLANs behind the Netgate firewall. Guest laptops connect directly to this edge network and never see the internal addressing or routing of the home office or cybersecurity lab.
This creates a simple three-tier boundary:
- Public internet
- Untrusted ISP/guest edge
- Fully controlled, segmented environment behind Netgate and Catalyst
Part 4: Cybersecurity Lab
The cybersecurity lab is being designed to support realistic attack and defense scenarios within a controlled, air‑gapped network segment (VLAN 20).
The hardware currently ready for setup includes a laptop, Cisco Catalyst switch, Netgate router/firewall, and Raspberry Pi boards.
An extensive testing period will verify functionality before actual cybersecurity simulations begin.
A compact lab in the beginning forces me to really understand each “brick”: how is the OS installed and the IDE installed on the Raspberry Pi, how the network is wired, what logs appear when I operate it. Omitting the deliberate introduction of vulnerable software at this stage is absolutely necessary, in order to first gain experience with a clean setup.
After that I will focus on exploring which combinations of devices and software best support the learning objectives aligned with the CISSP preparation and Security Architect Nanodegree.
Raspberry Pi and IoT Security Research
The lab will include multiple Raspberry Pi boards for specialized security research:
Raspberry Pi 5 (primary IoT research platform):
- 4–8 GB RAM, SSD‑class storage
- Acts as a fully‑fledged Linux host
- Run custom Python security research projects, IoT simulations, or lightweight services
Raspberry Pi Zero W / Pico W (low‑cost microcontroller‑class devices):
- P4wnP1 A.L.O.A. – specialized security image that emulates USB devices (keyboard, network interface)
- Simulates BadUSB attacks; useful for understanding hardware‑based attack vectors
- Practice securing endpoints against physical attack vectors
Thonny IDE (cross‑platform Python environment):
- Accessible workflow for flashing code and interacting with the REPL
- Exchange data between development laptop and Raspberry Pi
- Experiment with IoT sensor integration and basic network protocols
IoT Security Scenarios to Practice
- Deploy vulnerable IoT applications (e.g., old firmware versions of smart home devices).
- Practice Wi‑Fi security testing (WPA2/WPA3 cracking in a lab context).
- Simulate IoT botnets and understand IoT‑to‑C2 communication patterns.
- Monitor IoT device behavior in the SIEM to detect anomalies.
Malware Analysis and Sandboxing
In the second phase – after having gained confidence and experience in a clean setup – I will build an isolated malware research environment.
Then I could run a dedicated container specifically for binary analysis and reverse engineering, by using these tools:
- Cuckoo Sandbox (free, open-source malware analysis framework) – automated dynamic analysis
- IDA Free / Ghidra (NIST reverse engineering tool) – static analysis, disassembly
- Volatility – memory forensics; practice post‑mortem incident analysis
Safety measures:
- Malware analysis VM must be air‑gapped within VLAN 20, never bridged to the home network.
- Disable internet access; use snapshot/revert workflow.
- Copy samples from the Kali attacker VM via an isolated file share; never download from the internet.