IoT ProjectsIoT SecurityAdvanced

Project: building a safe, segmented IoT test lab

By Mohamed Fayas 10 min readUpdated 8 October 2026

In short: A good IoT lab keeps untrusted devices away from your real network while letting you watch everything they do. This project uses a firewall and VLANs to create management, IoT, services and quarantine zones, with packet capture and DNS logging. It is the safe base for every other IoT security exercise.

Why a separate lab, and what you need

Cheap smart devices often phone home to unknown servers, run outdated software or ship with weak defaults. If you test them on your home or work network, a weakness in the device becomes a weakness in everything else. A segmented lab lets you study them, practise hardening and capture traffic without that risk.

Part	Role
Small PC or appliance with two network ports	Runs OPNsense or pfSense as router and firewall
Managed switch with VLAN support and port mirroring	Separates zones and copies traffic for capture
Access point that supports multiple SSIDs mapped to VLANs	Wireless devices join the correct zone
Raspberry Pi or small server	MQTT broker, DNS resolver and capture host
Admin laptop with Wireshark and Nmap	Analysis from the management zone

Design

Figure 1. A firewall routes between separate lab VLANs and enforces which zone may talk to which.

Use an address plan that is easy to read, such as 192.168.10.0/24 for management, 192.168.50.0/24 for IoT test, 192.168.60.0/24 for services and 192.168.99.0/24 for quarantine. The lab firewall connects upstream to your normal router as if it were just another client, so the lab is a network behind a network. The firewall rules, read top to bottom, look like this:

Source	Destination	Allow	Why
Management	All lab zones	Yes	Administration and testing
IoT test	Services: TCP 8883, UDP 53	Yes	MQTT over TLS and DNS only
IoT test	Internet	Selected hosts only	Allow-list for updates you have reviewed
IoT test	Management, home LAN	No	Devices must never reach admin or home systems
Quarantine	Lab DNS only	Logged	Observe what the device tries to contact
Any	Any	No (logged)	Default deny

Build steps

Install the firewall, change default passwords, enable its web interface on the management VLAN only, and update it.
Create the four VLANs on the firewall and switch, tag the uplink as a trunk and set access ports for each zone.
Map an SSID to each wireless zone, using WPA3 or WPA2 with a strong passphrase per SSID.
Write the rules above, with logging on the deny rules, and test them: from the IoT VLAN, a ping to the management gateway must fail.
Point lab DHCP at the Pi's DNS resolver and enable query logging.
Configure a mirror port and capture traffic for a test device:

sudo tcpdump -i eth1 -w lab-device01.pcap host 192.168.99.23
nmap -sV -p- 192.168.99.23
nmap -sU --top-ports 50 192.168.99.23

Scan only devices you own, inside your lab. Open the capture in Wireshark and look at the DNS names the device resolves, whether it uses TLS, and whether anything is sent in clear text.

Workflow and lab safety checklist

Figure 2. New devices start isolated, are observed and assessed, and only then get the minimum access they need.

Own the equipment or have written permission; never test devices or cloud services you are not authorised to test.
No bridges: lab devices must not have a second path to your home network, such as a dual-homed laptop or a shared Wi-Fi.
Default deny with logging; add allow rules one at a time.
Snapshot and reset: keep firewall config backups and factory-reset devices after risky tests.
Protect captures: packet captures can contain credentials and personal data; store them encrypted and delete them when done.
Update the lab itself: the firewall and Pi need patching just like production systems.

Practice

Why does a new device start in a quarantine VLAN with no internet access?

So you can observe what it tries to contact through DNS logs and captures before allowing anything, and so it cannot download or leak data in the meantime.

What test proves the IoT VLAN cannot reach management systems?

From a device or test host in the IoT VLAN, try to ping or connect to the management gateway and admin hosts; the attempts must fail and appear in the firewall's deny log.

Why should packet captures from the lab be protected?

They may contain credentials, tokens, personal data or device secrets sent in clear text, so they need the same care as any sensitive data.

Key takeaways

A lab keeps untrusted IoT devices away from your real networks.
Use a firewall and VLANs for management, IoT, services and quarantine zones.
Default deny with logging, then allow only the flows a device needs.
Capture traffic and log DNS to learn what each device really does.
Test only equipment you own or are authorised to test, and protect captures.

Tracks your learning on this device only. See your progress on the learning paths.

About the author

Mohamed Fayas

Founder of FM TecHub. CCNA certified, with a BTEC HND in Network Engineering, and BEng (Hons) in Computer Networking and Cloud Security. He writes practical, plain-English guides on networking, security and cloud.

More about the author