Domain Specific Language

Segmenting my home network for defence in depth

  1. Introduction
  2. Legacy network topology
  3. New network layout
    1. Virtual Network & WiFi
    2. IP Groups
    3. Firewall rules
    4. mDNS discovery
  4. Moving my IoT devices over to the new WiFi-IoT SSID
  5. Future improvements
  6. References

I generally know what's installed and running on my home computers, but I don't know what's running on managed devices like Zigbee temperature loggers, Sonos speakers, or Chromecasts. I finally managed to segment my home network into multiple VLANs to achieve defence in depth1.

Introduction

I use a Dream Machine Pro 2 as my router, which is mounted in a 19"/37U rack. I've always dreamed of having my own rack (weird?), and now I have one — which feels great. The next thing on my list of wants for my homelab is a 1U or 2U RISC-V server. We're probably a few years from being able to buy actually good RISC-V commodity servers though.

When I got the Dream Machine Pro, I started out by creating a Guest network, but I hesitated creating an IoT network since I thought it would be a pain to move my devices over to the new network — and I was right, more on that later. The latest OpenSSH vulnerability, nicknamed regreSSHion3, was the last nail in the coffin for me. RegreSSHion isn't particularly related to rogue IoT devices, rather an increasing feeling of dread about how much bad C-code is running 24/7 in my home.

To get started, I needed some help, so I followed the steps in the excellent YouTube tutorial4 by Crosstalk Solutions, but that video is from July 2021 — almost 3 years ago. It was relatively simple to follow along, it was just a matter of finding where Ubiquiti had moved things in their UI since then.

When I told my friend Markus what I was doing, he joked that in 1999 his father had been right about the evil printer in their house and how it would spread viruses to their computer. After that I decided to move my printer into the IoT network, too.

Legacy network topology

Before restructuring my network setup I had my Default network and one Guest network, with them being segmented like this. The Guest network has access to the internet, but can't access anything in the Default network. The Default network can't access anything in the Guest network either. This is handled by the Dream Machine Pro's "Guest network" feature, that can be set as an option when creating a network. No additional firewall configuration is necessary.

Initial network topology

 ᯤ WiFi                  ᯤ WiFi-Guest
┌─────────────────┐     ┌─────────────────┐
│ Default         │     │ Guest (VLAN2)   │
│ 10.6.0.0/24     │     │ 192.168.1.0/24  │
└────────┬────────┘     └─────┬───────────┘
         │     ┌──────────┐   │
         └────►│ Internet │◄──┘
               └──────────┘

New network layout

After following the YouTube tutorial4, I ended up with the following topology:

New network topology

 ᯤ WiFi                  ᯤ WiFi-IoT              ᯤ WiFi-Guest
┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│ Default         ├────►│ IOT (VLAN3)     │     │ Guest (VLAN2)   │
│ 10.6.0.0/24     │     │ 10.7.0.0/24     │     │ 192.168.1.0/24  │
└────────┬────────┘     └────────┬────────┘     └────────┬────────┘
         │                  ┌────▼─────┐                 │
         └─────────────────►│ Internet │◄────────────────┘
                            └──────────┘

Which, honestly, doesn't say much. I'll try to give a few details.

The key thing is to not subnet yourself into a hole5 while doing this — in other words making sure that the VLAN you're in doesn't get firewalled in a way that makes it impossible to get out of without doing a factory reset on the router.

Virtual Network & WiFi

The first step is to add a new VLAN. It can be added under Network > Settings > Networks. I called my network IOT and gave it the IP range 10.7.0.0/24. My Default network already has 10.6.0.0/24 and my Guest network has 192.168.1.0/24.

Then I assigned a new WiFi SSID called WiFi-IoT and connected it to the IOT VLAN.

IP Groups

Time to create the following IP Groups, which can be done under Network > Settings > Profiles > IP Groups.

NameTypeSettings
Local Network RFC1918IPv4 Address/Subnet
  • 10.0.0.0/8
  • 192.168.0.0/16
  • 172.16.0.0/12
IoT to Other GW blockIPv4 Address/Subnet
  • 10.6.0.1
  • 192.168.1.1
All GW AddressesIPv4 Address/Subnet
  • 10.6.0.1
  • 192.168.1.1
  • 10.7.0.1
UDM-pro access portsPort Group
  • 80
  • 443
  • 22

Firewall rules

And then, the all-important firewall rules, which are configured under Network > Settings > Security > Traffic & Firewall Rules. All of these rules need to be marked "Before predefined".

NameTypeActionSourceDestinationMatch State
Allow established & relatedLAN InAcceptAnyAnyMANUAL: Established, Related
Allow Default to anywhereLAN InAcceptNetwork > DefaultPort/IP Group > Local Network RFC1918AUTO
Block inter-VLAN trafficLAN InDropPort / IP Group > Local Network RFC1918Port/IP Group > Local Network RFC1918AUTO
Block IoT To GWLAN LocalDropNetwork > IOTPort/IP Group > IoT to Other GW blockAUTO
Block IoT from UDM-Pro accessLAN LocalDropNetwork > IOTPort/IP Group > [Address Group] All GW Addresses, [Port Group] UDM-pro access portsAUTO

The first rule, Allow established & related, has to be the top / first one. It allows network connections to be established between the networks, and importantly it lets the IoT network connect back to the Default network once a device in the Default network has initiated a connection.

The second rule, Allow Default to anywhere, lets the Default network talk to any local network in the RFC1918 address space.

The third rule, Block inter-VLAN traffic, blocks all other inter-RFC1918 traffic.

The fourth rule, Block IoT To GW, blocks the IoT network from accessing the gateway IP-addresses in the Default network and the Guest network.

And lastly, The fifth rule, Block IoT from UDM-Pro access, blocks the IoT network from accessing the management interfaces on the router (ports 80, 443, and 22), without blocking it from accessing the gateway functionality it needs. The fourth rule already blocks the IoT network completely from the gateway interfaces on the Default network and the Guest network, so this technically only blocks it from the management ports on the IoT gateway, but the rule still prohibits the ports on all the gateways. Doing it like that prevents future changes from introducing mistakes — even though mistakes are still possible.

The firewall rules, working together

 ┌─────────────────┐       Connect: Allow        ┌─────────────────┐ 
 │ Default         ├────────────────────────────►│ IoT             │ 
 │ 10.6.0.0/24     │Response: Allow (Established)│ 10.7.0.0/24     │ 
 │                 │◄────────────────────────────┤                 │ 
---------------------------------------------------------------------
 │                 │        Connect: Deny        │                 │ 
 │                 │◄────────────────────────────┤                 │ 
 └─────────────────┘                             └─────────────────┘ 

Established & related connections are allowed, but unestablished or unrelated connections are denied. In the diagram we see communication between the Default network and the IoT network when the Default network initiates the connection. We also see that when the IoT network initiates a connection, and it is unestablished or unrelated, it is denied.

mDNS discovery

To get mDNS discovery working between the Default network and the IoT network, you need to set up "IoT Auto-Discovery" under Network > Settings > Networks > Multicast Settings > IoT Auto-Discovery, click edit and make sure the Default and IOT networks are both in the list.

Moving my IoT devices over to the new WiFi-IoT SSID

This was more painful than I had hoped it would be. More painful than it needs to be. I thought moving the Chromecast would be the easiest, then the Sonos and I honestly thought my Nedis Zigbee hub thing would be the most painful. Boy was I wrong!

The Sonos and the Chromecast were absolutely terrible to move over. Required a total factory reset of both devices. Is this the level of configurability we should expect from billion-dollar companies? I wasted a lot of time trying to figure out how to move them over, but it seems like it simply isn't possible to change the SSID or password on those devices, once configured. Let me know if I'm wrong.

The Nedis Zigbee thing was a breeze, took like 2 minutes. I guess that's the difference several billion dollars make.

Future improvements

One big thing would be to let the Guest network be able to access the IoT network to be able to use my Chromecasts, Sonos, etc. That would require me to stop using the convenient "Guest network" feature, but it shouldn't be too complicated to add the necessary firewall rules manually.

References

4

IoT Network Setup - UDM-Pro 2021 – https://youtu.be/UGBobTInIBc

5

Jessie Frazelle subnetting herself into a hole. This was fun at the time (2017) and I still remember it. The tweet is gone, though. https://blog.jessfraz.com/post/home-lab-is-the-dopest-lab/