I thought I'd document my relatively straightforward Omada deployment at home, explaining some of the rationale for my choices.

 

Background

Like many home users, I have 30+ devices on my network.

I upgraded my WAN bandwidth during the pandemic, which required a new router, and I was not going to lease that from my ISP.

I had played with VLANs using smart switches but it was cumbersome/incomplete.

I also wanted a centralized solution because I'm somewhat allergic to duplicate information across an heterogenous environment.

Given availability at the time, I chose tp-link gear.

 

Physical network

My physical network is entirely dictated by the house wiring. There's a panel in a closet radiating Cat5 to most rooms.

I also have access to the WAN there.

So the router, main switch, controller and AP are all colocated in that closet. The 2nd switch is in one room where I have a variety of clients.

I actually have another switch in a room where all the clients serve the same "purpose" so a dumb switch is used there.

By design, all clients that can be wired are wired. There are more than seen in the map which just displays those that are on right now.

Overall, it's pretty much what had to be done to get physical connectivity given the built-in wiring.

I'm one port short on the main switch which explains the machine directly plugged in router...

 

Logical network

Besides the learning opportunity with regards to networking, a flat network appeared somewhat dangerous with more and more clients in questionable state (either by default or no longer supported). I'll admit that my first attempt at segmentation resulted in getting locked out of my own network so I reset everything and started over.

My VLANs are grouping devices and clients according to their function.

• VLAN 1 (LAN): the native LAN with the Omada devices and occasionally the PC I use to manage the network (wired).
• VLAN 10 (PRODuctivity): PCs, Phones, printer.
• VLAN 55 (AMZN): Ring, Echos, Smart Thermostat.
• VLAN 100 (FUN): HDHomeRun, MediaCenter, XBox, FireTV cubes, TVs...
•  VLAN 250 (IOT): Wildlife Cam, smart switches...
• VLAN 254 (TEST): where I tinker/experiment before I post here. Good enough for guests.

I have corresponding SSIDs for PR0D,AMZN,IOT and TEST. Need to basis (e.g. none for FUN or LAN). Antenna also enabled on the same basis.

"Guest Network" is enabled on IOT and TEST. These VLANs are Wi-Fi only. Exceptions happen within TEST, for testing purposes.

I opted out of a MGMT (management) VLAN because everything about it looked like a PitA. Instead I don't allow anything in the native LAN.

 

There's really nothing special about the VLAN management aspect (followed the multi SSID guide).

Ports are configured with the standard Port Profiles (native network = untagged network = VLAN) according to devices connected to the port in question.

All the trunk ports (to other switch or gateway or AP) use the All profile.

 

My management PC is wired to LAN but Wi-Fi to PR0D. So I unplug the network cable accordingly...

 

Isolation

After my initial failure, for a while, I settled with the basic setup above. Likely tiny perf gain of segmenting the network, maybe some obfuscation from a security perspective.

A few months back, I started experimenting in the TEST VLAN until I felt I understood all ACL types thoroughly enough to re-implement them.

In that process, I realized my initial failure was caused by a misunderstanding of switch ACLs, in particular their stateless nature.

Using client/server terminology, they not only block request traffic from source-as-client to destination-as-server, they block all traffic from source to destination, INCLUDING source-as-server to destination-as-client (IOW, replies from server back to client in response to a client request).

 

My isolation requirements are relatively straightforward because they follow the VLAN boundaries.

So I have one gateway ACL LAN->LAN per VLAN (as source). The destination is the set of VLANs they have no business accessing.

For IOT and TEST, that's all but themselves. For FUN and PR0D, that's all more trusted (small VLAN ID) for now. I could be stricter there.

 

So far, I have not broken anything obvious...

 

Observations

• I wish I had notifications/logs generated when something is bumping against my ACLs. Right now, I'm flying blind. I might have compromised devices that probe around and I'd have no idea. I might also have legitimate use cases that I've broken but don't know about yet (I could investigate preemptively for log entries). I've requested this feature which appears to be available to MSPs.
• I dread having to fallback to switch ACLs if I need to poke holes (port level) in my existing rules... Their stateless nature is still unnatural to me.
• I wish the ACLs applied to cleaner boundaries. GW ACLs dealing with Inter-network traffic, Switch ACLs dealing with intra-network traffic. As of now, I feel the ACLs need to be set according to implementation limitations (e.g. no port at the GW LAN->LAN).
• My experimentations with AP ACLs have been a disaster because they don't apply when source and destination share the same AP/antenna/SSID. With a single AP and my segmentation approach, I even thought initially my AP plain failed to enforce them...

 

Next step

• OPSense bridge in front of the above setup. Supposedly, that can be plugged in and back out fairly transparently...
• DNS/DHCP. I'm a little tired of dealing with IP adresses on my internal network. DNS would address this but I will not settle for a solution that requires maintaining MAC->IP somewhere and IP->name somewhere else. IOW, DHCP leases need to update DNS. I experimented a bit with Ubuntu+dnsmasq and that was challenging with a VLAN setup. And then my NUC with that experiment became flaky (network plug loose?) which is unacceptable for that function. That OPNSense box might do the job too...

 

And with that, I'll disappear for a while (unless there are questions).

 

[PR0D with an O is against the rules...]