Welcome to Chapter 14! So far, we’ve explored the intricate worlds of firewalls, DNS, subnetting, packet analysis, and network monitoring. You’ve built a solid foundation of theoretical knowledge and hands-on skills. Now, it’s time to bring all these powerful concepts together in a practical, real-world project: building your very own secure home or lab network!

This chapter isn’t just about learning; it’s about doing. We’ll guide you through designing a network architecture that prioritizes security, privacy, and control, then help you implement it step-by-step using popular, open-source tools. You’ll configure a powerful firewall, set up a network-wide ad and malware blocker, and learn how to keep an eye on your network’s health and security. Get ready to transform your understanding into tangible results and build a network you can truly trust.

To make the most of this project, we’ll assume you’re comfortable with the core concepts covered in previous chapters, especially:

  • Firewall basics: Understanding rules, zones, and policies.
  • Subnetting: Dividing networks into smaller segments.
  • DNS fundamentals: How domain names are resolved.
  • Basic Linux command-line usage: For interacting with network devices.

Ready to become the architect and guardian of your own digital fortress? Let’s dive in!

Core Concepts: Designing a Fortified Network

Before we start typing commands, let’s lay down the foundational concepts for our secure network. A well-designed network is like a castle with multiple layers of defense, not just a single wall.

Network Segmentation: The Principle of Least Privilege

Imagine your home as a single, open room. If a burglar gets in, they have access to everything. Now, imagine your home with separate rooms, each with its own locked door. Even if a burglar enters one room, their access to other valuable areas is restricted. This is the essence of network segmentation.

What is it? Network segmentation is the practice of dividing a computer network into smaller, isolated sub-networks or “zones.” Each segment can then have its own security policies and controls, limiting communication between them.

Why is it important?

  • Containment: If one segment is compromised (e.g., an IoT device gets hacked), the attacker’s access is contained to that segment, preventing them from easily spreading to more critical parts of your network (like your personal computer or server).
  • Reduced Attack Surface: By isolating devices, you reduce the pathways an attacker can use to reach sensitive systems.
  • Improved Performance: Smaller broadcast domains can sometimes lead to better network performance, though security is the primary driver here.
  • Easier Management: Grouping similar devices (e.g., all smart home gadgets) makes it simpler to apply specific rules to them.

For our project, we’ll aim to create at least these logical segments:

  • WAN (Wide Area Network): The untrusted internet.
  • LAN (Local Area Network): Your trusted devices (PCs, laptops, phones).
  • IoT (Internet of Things) Zone: Smart devices (thermostats, cameras, smart speakers). These often have weaker security and need isolation.
  • Guest Zone: For visitors, providing internet access but no access to your internal network.
  • Lab Zone: An optional, isolated area for experimentation, testing, or running servers.

Let’s visualize this segmented network:

graph TD Internet[Untrusted Internet] Router[Router Firewall] subgraph SecureHomeLabNetwork["Secure Home Lab Network"] Router --> Control_Plane[Control Plane] Router --> LAN_Zone[Trusted Devices] Router --> IOT_Zone[Smart Devices] Router --> Guest_Zone[Visitors] Router --> Lab_Zone[Experimentation Servers] end LAN_Zone --> Controlled_Access[Controlled Access] IOT_Zone --> Controlled_Access Guest_Zone --> Controlled_Access Lab_Zone --> Controlled_Access IOT_Zone --> Limited_Internet[Limited Internet] Limited_Internet --> Internet Guest_Zone --> Isolated_Internet[Isolated Internet] Isolated_Internet --> Internet Lab_Zone --> Experimentation_Internet[Experimentation Internet] Experimentation_Internet --> Internet style Internet fill:#f9f,stroke:#333,stroke-width:2px style Router fill:#ccf,stroke:#333,stroke-width:2px style LAN_Zone fill:#cfc,stroke:#333,stroke-width:2px style IOT_Zone fill:#ffc,stroke:#333,stroke-width:2px style Guest_Zone fill:#fcc,stroke:#333,stroke-width:2px style Lab_Zone fill:#cff,stroke:#333,stroke-width:2px

In this diagram, the Router/Firewall acts as the central gatekeeper, mediating all traffic between the Internet and your internal zones, and critically, between your internal zones themselves. The “Controlled Access” arrows signify that specific firewall rules will dictate what traffic is allowed.

Firewall Strategy: Ingress, Egress, and Stateful Inspection

With segmentation in place, our firewall becomes the enforcer.

  • Ingress Filtering: Rules that inspect incoming traffic into a network segment. For example, blocking unsolicited connections from the IoT zone into the LAN zone.
  • Egress Filtering: Rules that inspect outgoing traffic from a network segment. This is crucial for IoT devices; you might only allow them to connect to specific manufacturer servers on specific ports, blocking them from talking to malicious sites.
  • Stateful Inspection: Modern firewalls track the “state” of connections. If you initiate an outgoing connection (e.g., browsing a website), the firewall automatically allows the return traffic for that specific connection. This is why you don’t typically need a rule to allow incoming web traffic if you initiated the request.

Our strategy will be: “Deny by Default, Permit by Exception.” This means all traffic between zones is blocked unless we explicitly create a rule to allow it. This is the most secure approach.

Secure DNS: The First Line of Defense

DNS (Domain Name System) is often called the “phonebook of the internet.” Securing it is vital.

  • DNS Filtering (Sinkholing): Tools like Pi-hole or AdGuard Home act as local DNS servers. They block known ad servers, malware domains, and tracking sites by resolving them to a non-existent IP address (a “sinkhole”). This protects all devices on your network.
  • DNS-over-TLS (DoT) / DNS-over-HTTPS (DoH): Encrypting your DNS queries prevents eavesdropping and manipulation by your ISP or other third parties. Your router can be configured to use these secure protocols when forwarding requests to external DNS providers.

Network Monitoring: Keeping an Eye on Things

Even with strong defenses, continuous vigilance is key.

  • Logs: Your firewall and DNS filter will generate logs. These are invaluable for understanding network activity, troubleshooting issues, and identifying potential security incidents.
  • Packet Analysis: Tools like Wireshark allow you to capture and inspect individual data packets. This is your magnifying glass for truly understanding what’s happening on your network, verifying firewall rules, and detecting suspicious traffic.

Step-by-Step Implementation: Building Your Secure Lab

For this project, we’ll use a powerful and flexible open-source router firmware: OpenWrt. It runs on many consumer routers, turning them into highly configurable network devices. For DNS filtering, we’ll use Pi-hole, a very popular and effective solution.

Tools You’ll Need:

  1. An OpenWrt Compatible Router: Check the OpenWrt Table of Hardware for compatible devices. We’ll assume you have OpenWrt installed (version 23.05.3 or newer, as of December 2025). If not, refer to the OpenWrt Installation Guide for your specific device.
  2. A Raspberry Pi (or similar small single-board computer) for Pi-hole: Install a lightweight Linux distribution like Raspberry Pi OS Lite.
  3. A Computer with Wireshark: For network analysis.
  4. Basic Ethernet Cables: To connect devices.

Step 1: Planning Your Network IP Address Scheme (Subnetting in Action!)

Before touching any configurations, let’s plan our subnets. We’ll use private IP address ranges.

  • WAN (Internet): Your ISP provides this IP.
  • Router (OpenWrt):
    • WAN Interface: DHCP from ISP.
    • LAN Interface: 192.168.1.1/24 (This will be the gateway for your trusted LAN).
  • Pi-hole Server: Static IP in the LAN zone, e.g., 192.168.1.10.
  • Network Zones:
    • LAN Zone: 192.168.1.0/24 (Addresses from 192.168.1.2 to 192.168.1.254) - Your main, trusted devices.
    • IoT Zone: 192.168.10.0/24 (Addresses from 192.168.10.2 to 192.168.10.254) - Smart home devices.
    • Guest Zone: 192.168.20.0/24 (Addresses from 192.168.20.2 to 192.168.20.254) - Guest access.
    • Lab Zone: 192.168.30.0/24 (Addresses from 192.168.30.2 to 192.168.30.254) - Servers, testing machines.

This gives us 254 usable IPs per subnet, which is plenty for a home/lab setup. Each /24 subnet means devices within that subnet can communicate directly, but communication between subnets must go through the router/firewall.

Step 2: Initial OpenWrt Setup: Interfaces and Basic Zones

Log into your OpenWrt router via SSH or the LuCI web interface. We’ll primarily use the command line (uci) for precision, but LuCI can be helpful for verification.

2.1. Verify Existing LAN and WAN Interfaces: OpenWrt usually has lan and wan interfaces configured by default. Connect via SSH:

ssh root@192.168.1.1 # Default OpenWrt IP

Check interfaces:

uci show network.lan
uci show network.wan

You should see something like:

network.lan=interface
network.lan.device='br-lan'
network.lan.proto='static'
network.lan.ipaddr='192.168.1.1'
network.lan.netmask='255.255.255.0'

network.wan=interface
network.wan.device='eth0.2' # Or similar, depends on your router
network.wan.proto='dhcp'

If your lan IP is different, adjust 192.168.1.1 in all subsequent steps to match your router’s LAN IP.

2.2. Create New Interfaces and DHCP Servers for IoT, Guest, and Lab Zones: For each new zone, we need:

  1. A new network interface (linked to a physical or virtual bridge).
  2. A new DHCP server to assign IPs to devices in that zone.
  3. A new firewall zone.

Let’s assume you have available Ethernet ports or can configure VLANs if your router supports it. For simplicity in this guide, we’ll create new virtual interfaces on the same physical LAN port for now (though in a real scenario, you’d use separate physical ports or VLANs for true isolation).

Important: This approach (br-lan for all) is simplified for demonstration. For true physical separation and enhanced security, you would assign each new interface to a separate physical Ethernet port or a separate VLAN on a managed switch.

# === Configure IoT Zone ===
echo "Configuring IoT interface and DHCP..."
uci set network.iot=interface
uci set network.iot.proto='static'
uci set network.iot.ipaddr='192.168.10.1'
uci set network.iot.netmask='255.255.255.0'
uci set network.iot.device='br-lan' # For simplicity, sharing physical interface.
                                   # In production, use a dedicated physical port or VLAN.

uci set dhcp.iot=dhcp
uci set dhcp.iot.interface='iot'
uci set dhcp.iot.start='100'
uci set dhcp.iot.limit='150'
uci set dhcp.iot.leasetime='12h'
uci set dhcp.iot.force='1' # Force DHCP server to start even if no devices are connected

# === Configure Guest Zone ===
echo "Configuring Guest interface and DHCP..."
uci set network.guest=interface
uci set network.guest.proto='static'
uci set network.guest.ipaddr='192.168.20.1'
uci set network.guest.netmask='255.255.255.0'
uci set network.guest.device='br-lan' # For simplicity, sharing physical interface.

uci set dhcp.guest=dhcp
uci set dhcp.guest.interface='guest'
uci set dhcp.guest.start='100'
uci set dhcp.guest.limit='150'
uci set dhcp.guest.leasetime='6h'
uci set dhcp.guest.force='1'

# === Configure Lab Zone ===
echo "Configuring Lab interface and DHCP..."
uci set network.lab=interface
uci set network.lab.proto='static'
uci set network.lab.ipaddr='192.168.30.1'
uci set network.lab.netmask='255.255.255.0'
uci set network.lab.device='br-lan' # For simplicity, sharing physical interface.

uci set dhcp.lab=dhcp
uci set dhcp.lab.interface='lab'
uci set dhcp.lab.start='100'
uci set dhcp.lab.limit='150'
uci set dhcp.lab.leasetime='24h'
uci set dhcp.lab.force='1'

# Commit changes
uci commit network
uci commit dhcp
/etc/init.d/network restart
/etc/init.d/dnsmasq restart

Explanation:

  • uci set network.iot=interface: Creates a new network interface configuration block named iot.
  • network.iot.proto='static': Assigns a static IP address to this interface.
  • network.iot.ipaddr='192.168.10.1', netmask='255.255.255.0': Sets the IP address and subnet mask for the IoT zone’s gateway.
  • network.iot.device='br-lan': This is the crucial part for our simplified setup. It means this new interface will “listen” on the same bridge (br-lan) as your main LAN. Devices connected to any LAN port will get an IP from one of the DHCP servers. Later, we’ll assign devices to specific zones by static IP or MAC address. For a real secure setup, you’d use a dedicated physical port (e.g., eth1) or VLANs (e.g., eth0.10).
  • uci set dhcp.iot=dhcp: Creates a DHCP server configuration block for the iot interface.
  • dhcp.iot.interface='iot': Links the DHCP server to our new iot interface.
  • start, limit, leasetime: Define the DHCP pool and how long IPs are leased.
  • force='1': Ensures the DHCP server starts even if no clients are immediately requesting IPs.
  • uci commit network and uci commit dhcp: Saves the changes permanently.
  • /etc/init.d/network restart, /etc/init.d/dnsmasq restart: Applies the changes by restarting the network and DHCP/DNS services.

Step 3: Configuring Firewall Zones and Policies

Now, let’s create the firewall zones and define their default behaviors. OpenWrt’s firewall uses nftables as its backend (as of versions 19.x+), making it robust and efficient.

# === Create Firewall Zones ===
echo "Creating firewall zones for IoT, Guest, and Lab..."

# IoT Zone
uci set firewall.iot_zone=zone
uci set firewall.iot_zone.name='iot'
uci set firewall.iot_zone.input='REJECT'  # Deny incoming to router from IoT
uci set firewall.iot_zone.output='ACCEPT' # Allow outgoing from router to IoT
uci set firewall.iot_zone.forward='REJECT' # Deny forwarding between IoT and other zones by default
uci set firewall.iot_zone.network='iot'

# Guest Zone
uci set firewall.guest_zone=zone
uci set firewall.guest_zone.name='guest'
uci set firewall.guest_zone.input='REJECT'
uci set firewall.guest_zone.output='ACCEPT'
uci set firewall.guest_zone.forward='REJECT'
uci set firewall.guest_zone.network='guest'

# Lab Zone
uci set firewall.lab_zone=zone
uci set firewall.lab_zone.name='lab'
uci set firewall.lab_zone.input='REJECT'
uci set firewall.lab_zone.output='ACCEPT'
uci set firewall.lab_zone.forward='REJECT'
uci set firewall.lab_zone.network='lab'

# Commit firewall changes
uci commit firewall
/etc/init.d/firewall restart

Explanation:

  • uci set firewall.iot_zone=zone: Creates a new firewall zone named iot_zone.
  • name='iot': A user-friendly name for the zone.
  • input='REJECT': This is critical! By default, no traffic from the IoT zone can initiate a connection to the router itself. This protects the router’s management interface.
  • output='ACCEPT': Traffic originating from the router to devices in the IoT zone is allowed (e.g., DHCP responses).
  • forward='REJECT': This is the core of our segmentation. By default, no traffic can be forwarded from the IoT zone to any other zone, nor can traffic be forwarded from any other zone to IoT. This implements our “Deny by Default” policy between zones.
  • network='iot': Links this firewall zone to the iot network interface we created earlier.
  • uci commit firewall, /etc/init.d/firewall restart: Saves and applies the firewall rules.

Now, let’s configure the lan zone to allow access to the router, but keep its forwarding policy strict.

# Modify default LAN zone forwarding to REJECT for security
echo "Modifying default LAN zone forwarding policy..."
uci set firewall.lan.forward='REJECT' # Deny forwarding from LAN to other zones by default
uci commit firewall
/etc/init.d/firewall restart

Why REJECT LAN forwarding? The default OpenWrt lan zone often has forward='ACCEPT'. By setting it to REJECT, we enforce explicit rules for LAN devices to talk to IoT, Guest, or Lab zones, strengthening our “Deny by Default” principle across all internal zones.

Step 4: Implementing Inter-Zone Firewall Rules (The “Permit by Exception” Part)

Now that everything is blocked by default, we need to add rules to allow necessary traffic.

4.1. Allowing Internet Access (WAN Forwarding): The default OpenWrt firewall configuration usually has rules to allow forwarding from lan to wan. We need to ensure our new zones can also reach the internet, but with specific controls.

echo "Configuring WAN forwarding rules for all internal zones..."

# Allow LAN to WAN (typically default, but good to be explicit for learning)
uci set firewall.lan_to_wan=forwarding
uci set firewall.lan_to_wan.src='lan'
uci set firewall.lan_to_wan.dest='wan'
uci set firewall.lan_to_wan.name='Allow LAN to WAN'

# Allow IoT to WAN
uci set firewall.iot_to_wan=forwarding
uci set firewall.iot_to_wan.src='iot'
uci set firewall.iot_to_wan.dest='wan'
uci set firewall.iot_to_wan.name='Allow IoT to WAN'

# Allow Guest to WAN
uci set firewall.guest_to_wan=forwarding
uci set firewall.guest_to_wan.src='guest'
uci set firewall.guest_to_wan.dest='wan'
uci set firewall.guest_to_wan.name='Allow Guest to WAN'

# Allow Lab to WAN
uci set firewall.lab_to_wan=forwarding
uci set firewall.lab_to_wan.src='lab'
uci set firewall.lab_to_wan.dest='wan'
uci set firewall.lab_to_wan.name='Allow Lab to WAN'

uci commit firewall
/etc/init.d/firewall restart

Explanation: These forwarding rules define that traffic originating from src zone is allowed to be forwarded to the dest zone. This is fundamental for internet access.

4.2. Specific Inter-Zone Rules:

  • LAN to IoT/Lab (Controlled Access):
    • Typically, devices in your LAN (your PC) might need to talk to IoT devices (e.g., smart home hub) or Lab servers (e.g., SSH into a test machine).
    • We’ll create a rule allowing LAN to initiate connections to IoT and Lab.
echo "Configuring LAN to IoT/Lab access rules..."

# Allow LAN to initiate connections to IoT devices
uci add firewall rule
uci set firewall.@rule[-1].name='Allow_LAN_to_IoT'
uci set firewall.@rule[-1].src='lan'
uci set firewall.@rule[-1].dest='iot'
uci set firewall.@rule[-1].target='ACCEPT'
uci set firewall.@rule[-1].family='ipv4' # Explicitly for IPv4

# Allow LAN to initiate connections to Lab devices
uci add firewall rule
uci set firewall.@rule[-1].name='Allow_LAN_to_Lab'
uci set firewall.@rule[-1].src='lan'
uci set firewall.@rule[-1].dest='lab'
uci set firewall.@rule[-1].target='ACCEPT'
uci set firewall.@rule[-1].family='ipv4'

uci commit firewall
/etc/init.d/firewall restart

Explanation:

  • uci add firewall rule: Creates a new, unnamed firewall rule. [-1] refers to the last added item.

  • src='lan', dest='iot': Traffic originating from the lan zone, destined for the iot zone.

  • target='ACCEPT': Allow this traffic.

  • Because OpenWrt’s nftables backend is stateful, this rule allows LAN to initiate connections to IoT and Lab. The return traffic will automatically be allowed.

  • Crucially, this does not mean IoT can initiate connections to LAN! That remains blocked by the default forward='REJECT' on the iot zone. This is a key security principle: LAN is more trusted than IoT.

  • IoT Zone (Strict Egress Filtering - Example):

    • IoT devices often “call home” to manufacturer servers. We should restrict them to only necessary communication. Let’s imagine an IoT device only needs HTTPS (port 443) to the internet.
echo "Configuring strict egress rules for IoT devices..."

# Block all IoT traffic to LAN (already done by default REJECT, but explicit rule can override specific ALLOWs)
# No need for explicit BLOCK here as 'forward REJECT' is already set for iot zone.

# Allow IoT to WAN only on specific ports (e.g., HTTPS 443)
# Note: This overrides the broader 'Allow IoT to WAN' for specific traffic.
# Rules are processed in order, so if a more specific REJECT comes first, it takes precedence.
# Let's refine this: We want to ALLOW only 443, and everything else is implicitly REJECTED by zone policy.
# So, we need to ADD a rule allowing 443, and ensure our general 'iot_to_wan' is restrictive.

# Let's adjust the `iot_to_wan` forwarding to be more restrictive
# First, remove the previous general IoT to WAN forwarding rule
uci delete firewall.iot_to_wan

# Then, add specific rules for IoT to WAN
# Allow DNS (UDP 53) to WAN (so IoT devices can resolve hostnames)
uci add firewall rule
uci set firewall.@rule[-1].name='Allow_IoT_DNS_to_WAN'
uci set firewall.@rule[-1].src='iot'
uci set firewall.@rule[-1].dest='wan'
uci set firewall.@rule[-1].proto='udp'
uci set firewall.@rule[-1].dest_port='53'
uci set firewall.@rule[-1].target='ACCEPT'

# Allow HTTPS (TCP 443) to WAN
uci add firewall rule
uci set firewall.@rule[-1].name='Allow_IoT_HTTPS_to_WAN'
uci set firewall.@rule[-1].src='iot'
uci set firewall.@rule[-1].dest='wan'
uci set firewall.@rule[-1].proto='tcp'
uci set firewall.@rule[-1].dest_port='443'
uci set firewall.@rule[-1].target='ACCEPT'

# Any other traffic from IoT to WAN will be implicitly rejected by the 'forward REJECT' on the iot zone.
# This makes our IoT zone very secure.

uci commit firewall
/etc/init.d/firewall restart

Explanation:

  • We first delete the broad iot_to_wan forwarding rule. This is crucial for “Deny by Default.”

  • Then we add specific rules: one for UDP port 53 (DNS) and one for TCP port 443 (HTTPS).

  • proto='udp' or proto='tcp': Specifies the protocol.

  • dest_port='53' or dest_port='443': Specifies the destination port.

  • Now, only DNS and HTTPS traffic will be allowed from IoT devices to the internet. Everything else is blocked. This is much stronger egress filtering.

  • Guest Zone (Isolated Internet Access):

    • Guests should only have internet access and be blocked from all internal networks. Our guest_zone.forward='REJECT' policy already handles this.
    • The guest_to_wan forwarding rule we added previously allows internet. No further rules are needed unless you want to block specific types of internet traffic for guests.

4.3. Assigning Devices to Zones (Static IPs or MAC Binding): Since we used br-lan for all interfaces, devices will initially get an IP from whichever DHCP server responds first. To assign a device to a specific zone (e.g., an IoT device to the 192.168.10.x subnet), you have two main options:

  1. Static IP on the Device: Manually configure the device (if it allows it) with an IP from the desired subnet (e.g., 192.168.10.5), subnet mask (255.255.255.0), and gateway (192.168.10.1).
  2. Static Lease (MAC Binding) on OpenWrt: Assign a specific IP address within a zone’s subnet to a device based on its MAC address. This is often preferred for IoT devices.

Let’s add a static lease for an imaginary IoT device (replace MAC address and IP):

echo "Adding a static DHCP lease for an IoT device..."

# Find the MAC address of your IoT device (e.g., from its settings or 'arp -a' on your PC)
# Example MAC: 00:11:22:33:44:55
# Example IP: 192.168.10.50

uci add dhcp host
uci set dhcp.@host[-1].name='MySmartBulb'
uci set dhcp.@host[-1].mac='00:11:22:33:44:55'
uci set dhcp.@host[-1].ip='192.168.10.50'
uci set dhcp.@host[-1].leasefile='/tmp/dhcp.leases' # For consistency, though often implied

uci commit dhcp
/etc/init.d/dnsmasq restart

Explanation: This tells the DHCP server to always give 192.168.10.50 to the device with MAC 00:11:22:33:44:55. The device will now belong to the IoT zone’s subnet and be subject to its firewall rules. Repeat this for all devices you want to assign to specific zones.

Step 5: Setting up Secure DNS with Pi-hole

Assuming you have a Raspberry Pi (or similar) with Raspberry Pi OS Lite installed and assigned a static IP in your LAN zone (e.g., 192.168.1.10).

5.1. Install Pi-hole on your Raspberry Pi: SSH into your Pi and run the official installer:

ssh pi@192.168.1.10 # Or whatever your Pi's IP is
curl -sSL https://install.pi-hole.net | bash

Follow the on-screen prompts. Choose 192.168.1.10 as its static IP during setup. Select your preferred upstream DNS providers (e.g., Cloudflare, Google, Quad9).

5.2. Configure OpenWrt to Use Pi-hole for DNS: This is crucial. We want all devices in our internal zones to use the Pi-hole for DNS resolution.

echo "Configuring OpenWrt to use Pi-hole as the DNS server..."

# Set Pi-hole as the DNS server for the LAN interface (and thus for DHCP clients in LAN)
uci set dhcp.lan.dns='192.168.1.10'

# Set Pi-hole as the DNS server for IoT zone
uci set dhcp.iot.dns='192.168.1.10'

# Set Pi-hole as the DNS server for Guest zone
uci set dhcp.guest.dns='192.168.1.10'

# Set Pi-hole as the DNS server for Lab zone
uci set dhcp.lab.dns='192.168.1.10'

# Ensure OpenWrt itself uses Pi-hole for resolution (optional, but good practice)
# This prevents OpenWrt from bypassing Pi-hole for its own queries.
# First, remove any existing external DNS servers from network.wan
uci delete network.wan.dns
# Add Pi-hole IP to network.wan.dns (or leave blank if it gets it from ISP and you want to ensure it uses Pi-hole)
# A more robust way is to make the router's internal DNS resolver (dnsmasq) forward to Pi-hole.
# By setting dhcp.zone.dns, clients get Pi-hole. The router itself will use its configured upstream.
# To ensure router uses Pi-hole, we need a specific config for dnsmasq or override system DNS.
# Let's override the system DNS for the router itself:
uci set network.wan.peerdns='0' # Don't use DNS servers advertised by ISP
uci add_list network.wan.dns='192.168.1.10' # Router itself uses Pi-hole

uci commit network
uci commit dhcp
/etc/init.d/network restart
/etc/init.d/dnsmasq restart # Important for DHCP changes to take effect

Explanation:

  • dhcp.zone.dns='192.168.1.10': This tells OpenWrt’s DHCP server for each zone to advertise 192.168.1.10 (your Pi-hole’s IP) as the DNS server to all clients in that zone.
  • network.wan.peerdns='0' and network.wan.dns='192.168.1.10': This forces the OpenWrt router itself to use your Pi-hole for its own DNS queries, rather than relying on your ISP’s DNS. This is a powerful step for consistent DNS security.

5.3. Firewall Rule for Pi-hole: We need to allow DNS queries from all internal zones to reach the Pi-hole server in the LAN zone. Remember our forward='REJECT' rules? They’re blocking this by default!

echo "Adding firewall rule to allow DNS queries to Pi-hole..."

# Allow DNS (UDP 53) from IoT to LAN (to Pi-hole)
uci add firewall rule
uci set firewall.@rule[-1].name='Allow_IoT_DNS_to_PiHole'
uci set firewall.@rule[-1].src='iot'
uci set firewall.@rule[-1].dest='lan'
uci set firewall.@rule[-1].proto='udp'
uci set firewall.@rule[-1].dest_port='53'
uci set firewall.@rule[-1].dest_ip='192.168.1.10' # Specify Pi-hole IP
uci set firewall.@rule[-1].target='ACCEPT'

# Allow DNS (UDP 53) from Guest to LAN (to Pi-hole)
uci add firewall rule
uci set firewall.@rule[-1].name='Allow_Guest_DNS_to_PiHole'
uci set firewall.@rule[-1].src='guest'
uci set firewall.@rule[-1].dest='lan'
uci set firewall.@rule[-1].proto='udp'
uci set firewall.@rule[-1].dest_port='53'
uci set firewall.@rule[-1].dest_ip='192.168.1.10'
uci set firewall.@rule[-1].target='ACCEPT'

# Allow DNS (UDP 53) from Lab to LAN (to Pi-hole)
uci add firewall rule
uci set firewall.@rule[-1].name='Allow_Lab_DNS_to_PiHole'
uci set firewall.@rule[-1].src='lab'
uci set firewall.@rule[-1].dest='lan'
uci set firewall.@rule[-1].proto='udp'
uci set firewall.@rule[-1].dest_port='53'
uci set firewall.@rule[-1].dest_ip='192.168.1.10'
uci set firewall.@rule[-1].target='ACCEPT'

uci commit firewall
/etc/init.d/firewall restart

Explanation: These rules explicitly permit UDP traffic on port 53 from the IoT, Guest, and Lab zones only to the IP address of your Pi-hole server in the LAN zone. This ensures all your devices use Pi-hole for filtering, without granting them general access to the entire LAN.

Step 6: Basic Network Monitoring with Wireshark

Now that your network is segmented and secured, let’s learn how to observe its activity.

  1. Install Wireshark: Download and install the latest stable version of Wireshark (v4.x as of 2025) on your computer from the official Wireshark website.

  2. Connect to a Mirror Port (Advanced) or Use the LAN Directly:

    • Ideal (Advanced): If your router or a managed switch supports port mirroring, you can mirror the traffic from the WAN port or a specific internal zone port to the port your Wireshark PC is connected to. This gives you a complete view without interfering with traffic.
    • Simple (for home lab): Connect your Wireshark PC to the LAN zone. You’ll primarily see traffic from your PC, to your PC, and broadcast traffic on the LAN. To see traffic from other zones, you’d need to connect your Wireshark PC to that zone, or use a managed switch with port mirroring.
    • OpenWrt tcpdump: For capturing traffic directly on the router’s interfaces, you can use tcpdump.

    Let’s use tcpdump on OpenWrt for a broader view.

    # Install tcpdump on OpenWrt if not already installed
opkg update
opkg install tcpdump

# Example: Capture traffic on the IoT interface
# This will show you what IoT devices are doing.
tcpdump -i iot -n -vvv

    Explanation:

    • tcpdump: The command-line packet capture tool.
    • -i iot: Capture on the iot interface. Replace iot with lan, guest, lab, or wan to monitor other zones.
    • -n: Don’t resolve hostnames (makes output faster and easier to read IPs).
    • -vvv: Very verbose output (shows more packet details).

  3. Basic Wireshark Filters (on your Wireshark PC): Once you have a capture (either directly from your PC’s interface or by transferring a tcpdump capture file to Wireshark), you can apply filters:

    • See all DNS queries: dns
    • See traffic to/from a specific IP (e.g., your Pi-hole): ip.addr == 192.168.1.10
    • See all HTTP/HTTPS traffic: http or tls (TLS is for HTTPS)
    • See traffic from an IoT device to the internet (after applying the strict rules):
      • First, identify your IoT device’s IP (e.g., 192.168.10.50).
      • Filter: ip.src == 192.168.10.50 and (udp.port == 53 or tcp.port == 443)
      • You should only see DNS and HTTPS traffic from that device. Any other traffic attempts will be blocked by the firewall and won’t appear as outbound.

What to Observe:

  • Pi-hole’s Effectiveness: Browse a website with ads. Check the Pi-hole admin interface (usually http://192.168.1.10/admin) to see blocked queries.
  • Firewall Rules in Action: Try to ping a device in the Guest zone from your LAN PC. It should fail! Check your Pi-hole logs or Wireshark captures for the blocked ICMP traffic.
  • IoT Device Behavior: Monitor your IoT devices. Are they trying to talk to unexpected IPs or ports? This is a sign of potential compromise or misconfiguration.

Mini-Challenge: Enhancing Guest Network Security

You’ve built a solid foundation! Now, let’s put your skills to the test with a practical challenge.

Challenge: Create a new firewall rule on your OpenWrt router to block all devices in the guest zone from accessing the web interface of your OpenWrt router itself (which is at 192.168.1.1 on port 80/443). Guests should only have internet access and DNS access to Pi-hole.

Hint:

  • You need a rule type.
  • The src zone is guest.
  • The dest is the device (the router itself).
  • Specify the proto and dest_port for web traffic (HTTP and HTTPS).
  • The target should be REJECT.
  • Remember to commit and restart the firewall!

What to Observe/Learn: After implementing the rule, try to access http://192.168.1.1 or https://192.168.1.1 from a device connected to your Guest network. You should see a connection refused or timeout error. This demonstrates direct control over access to your router’s management interfaces from less trusted zones.

Common Pitfalls & Troubleshooting

Building a secure network can be tricky. Here are some common issues and how to approach them:

  1. “I locked myself out of the router!”

    • Cause: A firewall rule was too broad or incorrectly applied, blocking your access to the router’s management interface.
    • Fix: If you have physical access, use OpenWrt’s failsafe mode (usually by holding a reset button during boot) to boot with a minimal configuration, allowing you to connect via SSH and revert your changes or factory reset. Always test rules carefully!

  2. “Devices in a zone aren’t getting IPs or can’t access the internet.”

    • Cause:
      • DHCP server for that zone isn’t running (/etc/init.d/dnsmasq status).
      • Network interface for the zone is not up or misconfigured (ifconfig or ip a).
      • Firewall forwarding rule to wan is missing or incorrect for that zone.
      • DNS resolution issues: Pi-hole is down, or the firewall isn’t allowing DNS traffic to Pi-hole.
    • Fix:
      • Check OpenWrt system logs: logread -f. Look for dnsmasq or netifd errors.
      • Verify interface status: ifconfig or ip a.
      • Check firewall rules: fw3 print (shows active nftables rules) or uci show firewall.
      • From a client device, try ping 8.8.8.8 (tests internet connectivity, bypasses DNS) then ping google.com (tests DNS). If 8.8.8.8 works but google.com doesn’t, it’s a DNS issue.

  3. “Pi-hole isn’t blocking ads, or devices can’t resolve anything.”

    • Cause:
      • Pi-hole server is offline.
      • OpenWrt isn’t advertising Pi-hole as the DNS server via DHCP for that zone.
      • Firewall rule blocking DNS traffic from the zone to the Pi-hole.
      • Devices are bypassing Pi-hole (e.g., hardcoded DNS, DNS-over-HTTPS clients).
    • Fix:
      • Check Pi-hole status: ssh pi@192.168.1.10 'pihole status'.
      • Verify DHCP settings on OpenWrt: uci show dhcp.lan.dns.
      • Check firewall rules for DNS to Pi-hole.
      • On a client device, verify the DNS server it’s using (e.g., ipconfig /all on Windows, scutil --dns on macOS, cat /etc/resolv.conf on Linux).

  4. “Traffic between zones is unexpectedly allowed/blocked.”

    • Cause: Firewall rule order matters! Broader ACCEPT rules might accidentally override more specific REJECT rules, or vice versa. Misunderstood input/output/forward policies.
    • Fix:
      • Use fw3 print on OpenWrt to see the actual nftables rules being applied. This is the ultimate source of truth.
      • Review your forward policies for each zone. Remember REJECT by default.
      • Test with ping and traceroute from various devices to understand the traffic path.
      • Use Wireshark/tcpdump to capture traffic and see exactly what’s being sent and where it’s being dropped. Look for “ICMP Host administratively prohibited” messages.

Summary

Congratulations! You’ve just completed a significant project that brings together many core cybersecurity and networking principles.

Here are the key takeaways from building your secure home/lab network:

  • Network Segmentation is Power: By dividing your network into isolated zones (LAN, IoT, Guest, Lab), you drastically reduce the attack surface and contain potential breaches.
  • Firewalls are Your Gatekeepers: OpenWrt’s firewall, powered by nftables, allows you to implement a robust “Deny by Default, Permit by Exception” policy between zones and to the internet.
  • DNS is a Critical Control Point: Pi-hole provides network-wide ad blocking, malware protection, and privacy enhancement by filtering DNS queries.
  • Vigilance Through Monitoring: Tools like Wireshark and tcpdump are indispensable for verifying your configurations, troubleshooting issues, and detecting suspicious activity.
  • The Importance of Planning: A well-thought-out IP addressing scheme and network topology are fundamental to a successful and secure deployment.
  • Iterative Security: Building a secure network isn’t a one-time task. It requires continuous monitoring, rule refinement, and staying updated with best practices.

This project has equipped you with practical skills to secure your own digital environment and a deeper understanding of how network security mechanisms truly operate. Keep experimenting, keep learning, and keep asking “what if?” to continually harden your network defenses.

What’s next? In the upcoming chapters, we’ll delve into even more advanced cybersecurity topics, including intrusion detection, vulnerability management, and securing cloud environments. Your secure home lab is now an excellent playground for these explorations!

References

This page is AI-assisted and reviewed. It references official documentation and recognized resources where relevant.