The Realms WAN: Build a Four-Region Homelab for Networking and Security Fundamentals

Overview

Many homelabs begin with a collection of virtual machines but never become a network. The machines share one virtual switch, receive addresses from the same DHCP server, and can all reach each other by default. That setup is useful for learning operating systems, but it does not force you to make the decisions that network administrators make: where one network ends and another begins, which router owns each gateway, how remote sites learn routes, where shared services belong, and which traffic should be allowed between zones.

The Realms WAN is a reduced enterprise-style lab designed to make those decisions visible. It contains four regions with distinct jobs: Minas Tirith is the headquarters and shared-services network; The Shire is a normal branch office; Rohan is a field-operations site with limited access; and The Watchtower is the management and monitoring network. The names make the topology easier to remember, but the design underneath is conventional. Replace the names with Headquarters, Branch, Field Site, and Network Operations Center and the same architecture could describe a small organization.

This is a general networking lab, not a penetration-testing range. The learning goals are addressing, subnetting, routing, DHCP, DNS, traffic analysis, segmentation, logging, documentation, and troubleshooting. Security appears where it belongs in normal network engineering: controlling management access, limiting unnecessary traffic, protecting the monitoring network, and proving that policy works. Students interested in network administration, infrastructure, cloud, support, or defensive security can all use the same build.

The lab can run entirely on one computer with VirtualBox or VMware Workstation. Ubuntu keeps the resource requirement manageable, and one optional Windows client adds operating-system diversity. A host with 16 GB of RAM can run the lab by starting only the systems needed for the current task; 32 GB makes it comfortable to run the full environment. The useful deliverable is not a screenshot of eight running VMs. It is a network that you can explain, validate, break, repair, and rebuild from your own documentation.

How it works

The complete topology uses four small Ubuntu router VMs and at least one client or service VM behind each router. Every regional router has two virtual network adapters. Its WAN adapter connects to a shared transit network used only by the routers. Its LAN adapter connects to a private virtual switch for that region. A regional client can reach its local router directly, but reaching another region requires Layer 3 forwarding across the transit network. This is what turns a group of VMs into a routed lab.

The address plan below keeps the first build predictable. The transit subnet belongs only to router WAN interfaces. Each territory receives its own /24 LAN, the router uses .1 as the default gateway, and the lower addresses remain available for infrastructure. The values are examples rather than hidden requirements; once the baseline works, redesigning the ranges and documenting the change is a useful follow-up exercise.

Routing can be introduced in two stages. Start with static routes because they expose every decision. Each router already knows its directly connected regional network and the transit network; you add a route for each remote region through that region's transit address. For example, The Shire router reaches Minas Tirith through 10.77.0.1, Rohan through 10.77.0.3, and The Watchtower through 10.77.0.4. Once the static design works, FRRouting and OSPF can replace the static routes. Comparing the route tables before and after that change makes the purpose of a dynamic routing protocol concrete.

Services give the topology a reason to exist. Minas Tirith can host central DNS, an internal web page, and shared files. The Shire can run DHCP for its branch clients. Rohan can contain a field workstation that needs only a narrow set of headquarters services. The Watchtower can collect Syslog messages, receive monitoring data, and act as the administrative jump point. These roles create traffic that can be measured and policy that can be tested. Without services, routing is only a successful ping; with services, you can ask whether a client receives the right configuration, resolves the right name, reaches the approved application, and produces useful logs when something fails.

Virtual networking terminology varies by hypervisor, but the required behavior is the same. Create one isolated transit switch shared by the four routers, then create four isolated regional switches. In VirtualBox, Internal Network mode works well and each network name acts as a separate virtual switch. In VMware Workstation, use custom host-only VMnets with the built-in DHCP service disabled. Do not bridge the regional networks to the physical LAN. Isolation prevents an experimental DHCP server, route, or firewall rule from interfering with the rest of your home network.

In practice

Step 1: draw the network before creating VMs. Put the four routers around the shared 10.77.0.0/24 transit network, then draw one regional LAN behind each router. Label every router interface, subnet, gateway, and virtual-switch name. Create an address worksheet with columns for region, system, interface, IP address, prefix, gateway, DNS server, and purpose. If an address does not appear in the worksheet, do not configure it yet. This prevents the topology from existing only in the hypervisor GUI.

Step 2: create the five virtual networks shown in the switch-layout table. Disable hypervisor-provided DHCP on all five. REALMS-TRANSIT should contain only router WAN interfaces. Each territory network should contain one router LAN interface and the local clients or servers. Before continuing, inspect every VM's adapter assignment in the hypervisor. A wrong switch selection looks like a bad IP configuration later, so this check is worth doing now.

Step 3: build one Ubuntu Server router template. Allocate one or two virtual CPUs, 512 MB to 1 GB of RAM, and a small virtual disk. Temporarily attach a NAT adapter if the VM needs internet access for package installation, install the tools below, then shut down and remove that temporary adapter. Keeping it would add a second default route and make later troubleshooting less predictable.

sudo apt update
sudo apt install -y iproute2 iputils-ping traceroute tcpdump dnsutils curl nftables

Clone the template four times and name the VMs rtr-minas, rtr-shire, rtr-rohan, and rtr-watchtower. Give every clone two adapters: adapter one on REALMS-TRANSIT and adapter two on its territory network. Start one router at a time until the interface mapping has been documented.

Step 4: identify interfaces before applying addresses. Interface names depend on the hypervisor and adapter order, so do not assume the first adapter is always enp0s3. Run the inspection commands, compare the MAC addresses with the hypervisor, and record which interface faces transit and which faces the LAN.

ip -br link
ip -br address

Create a Netplan configuration for each router. The example below is for Minas Tirith and assumes enp0s3 faces REALMS-TRANSIT while enp0s8 faces REALMS-MINAS. Replace those names if the inspection shows something different. The other three routers use the same structure with the addresses from the IP table.

network:
  version: 2
  ethernets:
    enp0s3:
      dhcp4: false
      addresses:
        - 10.77.0.1/24
    enp0s8:
      dhcp4: false
      addresses:
        - 10.77.10.1/24

Save the configuration under /etc/netplan, test it before committing the change, and then verify both addresses. Netplan try automatically rolls back if connectivity is lost and the change is not confirmed.

sudo netplan try
sudo netplan apply
ip -br address
ip route

Step 5: enable IPv4 forwarding on every router. A VM with two correctly addressed interfaces is still only a multihomed host until forwarding is enabled. Apply the setting, verify that the kernel accepted it, and repeat this on all four routers.

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-realms-router.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

Step 6: create one lightweight client in each territory. Ubuntu Server with 1 GB of RAM is enough, and a desktop interface is optional. Begin with static addresses so DHCP cannot hide an addressing or routing mistake. The example configures the Minas Tirith client; duplicate the pattern using .20.10, .30.10, and .40.10 addresses with the matching .1 gateway for the other territories.

network:
  version: 2
  ethernets:
    enp0s3:
      dhcp4: false
      addresses:
        - 10.77.10.10/24
      routes:
        - to: default
          via: 10.77.10.1

Step 7: validate one territory at a time. From each client, inspect its address and route table, ping its local gateway, and then ping the router's transit address. On the router, inspect neighbor discovery and capture ICMP on the LAN interface. Replace the example interface name and addresses with those for the territory being tested. Do not move to inter-territory routing until all four clients can consistently reach their local gateways.

# Run on the client
ip -br address
ip route
ping -c 4 10.77.10.1
ping -c 4 10.77.0.1

# Run on the territory router
ip neigh
sudo tcpdump -ni enp0s8 icmp

Step 8: add static routes between territories. Test routes temporarily first; a reboot removes them if the next-hop design is wrong. The following commands are for the Minas Tirith router. Each of the other routers needs one route for every remote territory through that territory router's transit address.

sudo ip route add 10.77.20.0/24 via 10.77.0.2
sudo ip route add 10.77.30.0/24 via 10.77.0.3
sudo ip route add 10.77.40.0/24 via 10.77.0.4
ip route

After the temporary routes pass testing, place them under the transit interface in the router's Netplan file so they survive reboot. This fragment belongs beneath the Minas Tirith transit interface definition.

routes:
  - to: 10.77.20.0/24
    via: 10.77.0.2
  - to: 10.77.30.0/24
    via: 10.77.0.3
  - to: 10.77.40.0/24
    via: 10.77.0.4

Step 9: prove the path instead of relying on one successful ping. From The Shire client, trace the route to the Minas Tirith client. The first hop should be 10.77.20.1, followed by the Minas Tirith router on the transit network, and then the destination. Capture the test on the Shire router to connect the route-table decision with the packets crossing each interface.

# Run on the Shire client
traceroute 10.77.10.10
ping -c 4 10.77.10.10

# Run on the Shire router in a second terminal
sudo tcpdump -ni any 'icmp or udp portrange 33434-33534'

Repeat the test between every pair of territories and record the results. Four territories create twelve directional paths. Testing all twelve catches missing return routes and asymmetric failures that one successful headquarters-to-branch test will not reveal.

Step 10: add services in layers. Begin with a small web service on the Minas Tirith client and prove that every territory can reach it by IP address. This temporary service is intentionally simple; it provides application traffic without introducing a full web-server configuration.

# Run on the Minas Tirith client
mkdir -p ~/realms-portal
printf 'The Realms WAN is operational.\n' > ~/realms-portal/index.html
python3 -m http.server 8080 --directory ~/realms-portal

# Run from each remote territory
curl http://10.77.10.10:8080

Once IP-based access works, add central DNS in Minas Tirith and create a name such as portal.realms.lab. Then add DHCP to The Shire, migrate only the Shire client from static addressing, and verify its lease, gateway, and DNS settings. Finally, add remote Syslog collection in The Watchtower. Validate one service before introducing the next so each failure has a small search area.

Step 11: add segmentation only after the open routed network is understood. Start with a short policy based on the territory roles, not with a large ruleset copied from another environment.

The following nftables example enforces one part of that policy on the Watchtower router: user territories cannot initiate connections into the management LAN, while established replies and Watchtower-initiated administration continue to work. Validate the file before loading it. Expand the rules only after this narrow control behaves as expected.

table inet realms_filter {
  chain forward {
    type filter hook forward priority 0; policy accept;

    ct state established,related accept
    ip saddr { 10.77.10.0/24, 10.77.20.0/24, 10.77.30.0/24 } ip daddr 10.77.40.0/24 limit rate 5/minute log prefix "REALMS-WATCHTOWER-DROP "
    ip saddr { 10.77.10.0/24, 10.77.20.0/24, 10.77.30.0/24 } ip daddr 10.77.40.0/24 drop
  }
}

sudo nft -c -f /etc/nftables.conf
sudo nft -f /etc/nftables.conf
sudo nft list ruleset
sudo systemctl enable nftables

Step 12: introduce troubleshooting scenarios. Remove a return route, enter the wrong prefix length, point a client at the wrong gateway, stop the DNS service, disable forwarding, attach one NIC to the wrong virtual switch, or place a deny rule above an allow rule. Diagnose each failure with the same process: identify the symptom, establish the scope, test from the nearest known-good point, move one layer or hop at a time, make one change, retest, and document the cause and fix. Reverting random settings until traffic returns may repair the lab, but it does not build troubleshooting skill.

Step 13: save a known-good baseline. Export the topology and address plan, copy the router configurations outside the lab, and take snapshots only after the full validation matrix passes. Your final lab portfolio should include a logical diagram, virtual topology, IP plan, routing table summary, service inventory, firewall policy, validation results, change log, and at least two troubleshooting reports. Those artifacts demonstrate networking skill more clearly than the number of VMs running on the host.

Common mistakes

Building everything before testing anything is the fastest way to create a lab that is difficult to debug. If routing, DNS, DHCP, and firewall policy are introduced together, one incorrect setting can produce several misleading symptoms. Build in layers: local connectivity, forwarding, static routes, cross-region validation, name resolution, address assignment, logging, and finally segmentation. Keep a known-good checkpoint after each layer.

Using the same virtual switch for multiple regions silently collapses the topology. Clients may communicate directly at Layer 2 even though the diagram says traffic crosses a router. Check the adapter assignment in the hypervisor and verify with packet captures. A broadcast from The Shire should never appear on the Rohan LAN interface. If it does, the virtual networks are not isolated the way the diagram claims.

Forgetting return routes creates one-way traffic. The source router knows how to reach the destination, but the destination router does not know how to return to the source network. Ping reports a timeout, which often leads beginners to change firewalls even though the forward path worked. Inspect the route table on both ends and capture traffic near the destination. Seeing an echo request arrive without an echo reply returning is strong evidence of a return-path problem.

Adding internet access too early makes the lab harder to reason about. NAT adapters inject additional default routes, DNS servers, and DHCP behavior. Build and validate the isolated WAN first. If packages are required, temporarily attach a NAT adapter, update the VM, then remove it and confirm the original routing table is restored. The lab should not depend on internet connectivity to demonstrate its core functions.

Treating ping as complete validation hides application problems. ICMP can work while DNS, DHCP, web traffic, or administrative access fails. It can also be blocked while an approved application works correctly. Define a test for each requirement: use dig or nslookup for DNS, inspect the lease for DHCP, use curl for HTTP or HTTPS, use SSH for administration, and search The Watchtower logs for monitoring. The protocol being tested should match the requirement being proved.

Skipping documentation turns every later change into rediscovery. Record interface names, MAC addresses, virtual-switch assignments, routes, service ports, and policy decisions as you build. Update the diagram when the network changes, not at the end of the project. If the diagram and the running configuration disagree, the running configuration is not automatically correct; the disagreement is a change-management problem that needs to be resolved.

Defensive guidance

Keep The Realms WAN isolated from networks that contain personal devices, work systems, or real credentials. Internal or host-only virtual switches are the safe default. If the host needs to manage the lab, permit only the management path required for that task. Do not bridge every VM onto the home LAN, and do not enable inbound port forwarding from the internet. This lab does not need public exposure to teach routing, services, monitoring, or firewall policy.

Use fake data and lab-only credentials. The Watchtower collects logs and the headquarters region hosts shared services, so both can accumulate usernames, addresses, and activity history. None of that should come from real accounts. Store administrative passwords in a password manager, use unique credentials for the lab, and avoid embedding passwords in diagrams or screenshots that may later be shared publicly.

Protect the management plane more strongly than the user regions. The Watchtower should be able to administer routers, but ordinary clients should not be able to initiate connections into The Watchtower. Use SSH keys instead of password-only administration, restrict SSH by source network, disable direct root login, and log successful and failed administrative sessions. A management network is valuable only if it is actually treated as a different trust zone.

Back up configurations outside the environment they rebuild. Keep Netplan files, nftables rules, DNS records, DHCP scopes, diagrams, and validation checklists in a private repository or another storage location that survives the loss of the host. Snapshots are useful for quick rollback but are not a substitute for a rebuild procedure. The strongest proof that the documentation works is rebuilding one router from a clean template using only the documented steps.

Use logging to verify policy, not to collect noise. Send router and service logs to The Watchtower, synchronize time with NTP, and record the expected source, destination, protocol, and result for each validation test. Rate-limit firewall-deny logging so one mistake does not fill the disk. The goal is to connect a packet-level event to a route, a rule, a service, and a timestamp that can be explained.

Expand the lab only when the current version is stable. Good next steps include OSPF with FRRouting, VLANs inside Minas Tirith, a Windows client, redundant DNS, a site-to-site VPN replacing one transit path, SNMP monitoring, or configuration automation with Ansible. Add one capability at a time and repeat the validation matrix after each change. Complexity creates learning value only when you can still explain the traffic path and recover from a failure.

The finished Realms WAN is a reusable practice environment for Network+ concepts and real operational habits. It teaches the difference between a subnet and a site, between reachability and service availability, between a route and a security policy, and between a working configuration and a documented, supportable system. Those skills apply whether the next step is network administration, cloud infrastructure, technical support, or defensive cybersecurity.