The Threat of the Toaster

We fill our homes with “Smart” devices. Smart bulbs, smart plugs, smart fridges. These devices are usually running year-old firmware, have hardcoded credentials, and are phoning home to servers in random countries. I don’t trust them. They do not belong on my main Trusted LAN (10.42.0.x) where my NAS and SSH keys live. They belong in the Quarantine Zone.

The Goal

I wanted to set up a specific physical port (ether17) on my MikroTik CSS switch to be a dedicated “Dirty Port”. Any wireless access point or device plugged into that port should be instantly tagged onto VLAN 90 (Quarantine). It should not be able to see VLAN 1 (Trusted) traffic. It should only be allowed to go out to the Internet (via the OPNsense firewall) and nowhere else.

The Troubleshooting Session

My MikroTik switch is powerful, but SwOS (SwitchOS) can be intuitive… or infuriating. I was hitting a weird issue: ether17 showed as “Disabled” and “Hardware Offload Locked”. I couldn’t change the PVID.

Step 1: Nuke and Pave

The port configuration had drifted into an undefined state. The fix was to delete the bridge port entry entirely and recreate it.

1. Remove ether17 from the bridge configuration.
2. Add it back fresh.
   • PVID: 90.
   • Hw. Offload: Unchecked (for now, to debug).

Setting the PVID (Port VLAN ID) to 90 is critical. This tells the switch: “Any packet entering this port without a tag should be stamped with ‘90’ immediately.”

Step 2: The Bridge VLAN Table

This is where beginners (including me) trip up. In the VLANs tab, we define where VLAN 90 is allowed to go.

• VLAN ID: 90
• Tagged Ports: ether1-FIREWALL
• Untagged Ports: ether17

Why?

• Tagged (ether1-FIREWALL): This is the trunk line going to the router (OPNsense). The router needs to know which network this packet belongs to. So we keep the tag “90” on it.
• Untagged (ether17): The smart toaster or cheap WiFi AP plugged into ether17 doesn’t know what a VLAN is. It just speaks plain Ethernet. The switch must strip the tag before sending the packet out to the device, and add the tag when receiving from the device.

The Mistake I Made

I initially had ether1-FIREWALL in the Untagged list. This meant traffic for VLAN 90 was arriving at the router without a tag. The router assumed it was VLAN 1 (Default). Suddenly, my “Quarantine” devices were dropping onto the Management LAN. Security Disaster.

Fixing the list—moving ether1-FIREWALL to Tagged—sealed the quarantine.

Verification: Trust But Verify

Never assume a VLAN works just because the UI looks right. I verified this with a “Penetration Test Light”.

1. Plug in a laptop to ether17.
2. Check IP: Received 192.168.90.50 (Quarantine Range). Correct.
3. Ping Gateway: ping 192.168.90.1. Success.
4. Ping Trusted Gateway: ping 10.42.0.1. Request Timed Out. (Blocked by Firewall).
5. Scan Trusted Subnet:

   nmap -sn 10.42.0.0/24

   Result: 0 hosts up.

This confirmed that even if a “smart” lightbulb is compromised, the attacker is trapped in a small glass box. They can scream into the void (The Internet), but they cannot touch the crown jewels (The NAS).

Conclusion

VLANs are not just for enterprise. If you have “Smart” devices, you need them. Hardware segregation (configuring the switch port itself) is safer than relying on WiFi SSID segregation alone. Even if someone hacks the WiFi AP, the packets entering the switch are forced into VLAN 90 by the PVID. The physics of the port enforce the security.

---