This post documents the re-introduction of VLANs to our home network, removed in 2018 to solve problems with 4-year old WAP and power-line adapters their replacement means we can move back to more secure and flexible networking set-up.

Background

Back in 2015 I attempted to introduce VLANs into my home network, to separate trusted (inside the firewall) from untrusted (outside the firewall) traffic that, out of necessity at the time, had to travel down the same physical network cable. I maintained this when I moved home but I encountered problems with traffic from supposedly VLAN-separated subnets appearing on the wrong VLAN interface on my router - I suspected that either my power-line adapters or wireless access points [WAPs] were corrupting the traffic. In the end, I removed the VLANs entirely as they weren’t an absolute (functional) necessity in the new house.

In the new house I had to acquire a 2nd WAP, as one would not cover the whole house, but despite this we still have some wireless dead spots and it would be nice if the wireless extended a little into the back garden. The amount of kit on our home network has also grown considerably as the internet of things (IoT) had arrived and we find our home is now shared with internet-connected central heating, Amazon Echo Dots, CCTV and even TVs. Due to being unable to get the VLAN infrastructure to work, I also had to ditch my plan to have a dedicated guest wireless network for visiting family and friends. Our existing 8 year old WAPs also pre-date consumer level wireless meshing, so our (sort of) whole-home wireless coverage is achieved through having two access points with the same SSID and key - not ideal but mostly functional.

Today

Over the last 3 weeks I have installed physical CAT 6 cabling and sockets between the room we use as an office and everywhere we need network connectivity. This has (mostly) eliminated the power-line network, except for one CCTV camera which will not connect to our current wireless network due to the PSK being too long for its configuration utility.

Today I have taken delivery of new wireless access points, TP-Link’s EAP225, and a 24-port POE+ managed switch. The switch will replace our current 8-port managed core switch and power the new access points via the new cabling, and will be UPS-backed (as the current switch is). The physical wiring, modern business-grade WAPs should allow me to re-instate some of the old segregation I had - although not all as some kit, such as Sky’s Sky Go app and Plex, make assumptions based on if they are on the same subnet as the equipment they talk to (although Plex is apparently configurable). I need to consider if jumping onto the IoT wireless to use streaming with the Sky Q boxes is too inconvenient to do the sensible thing and segregate them from the systems with high-value data (i.e. our desktops and NAS).

VLAN plan

It’s good to have a plan, so here’s an initial one:

VLAN ID Purpose
10 Switch management/configuration
20 Main network (desktops/NAS)
(21) (Possible separate network for networked printers)
30 IoT network (Sky, central heating, Echos)
31 IoT CCTV network
40 Guest network

Configuring the switch

Originally I was going to just configure my existing switch, which is the same switch as I had back in 2015, and attach the new switch to a port to configure it prior to swapping it out. However, the old switch was full and as they are going to have to be swapped anyway I decided it made sense to do that first and then configure the new one in situ. I then found that the new switch doesn’t have a single, system, management interface but that multiple can be configured on different VLANs or specific ports turned into management ports. This is much more flexible but pushed me back to having to pre-configure it, and the router, before I can swap them over.

The new switch is a TP-Link T1600G-28PS JetStream 24-Port Smart Managed Rackmount Gigabit PoE+ Switch (192W).

Annoyingly, just like the old switch, the new one comes factory set to a static IP of 192.168.0.1, which conflicts with my router, and unlike the old switch the new one do not have a serial/console port that is present on more expensive models. This means the only way to do the initial configuration is to reconfigure the Ethernet port on a system to talk to it via a direct connection in isolation from the rest of the network. I think on the new management network I will configure the router’s IP address to be x.250 instead of x.1 so that if I acquire a similar new switch in the future I can hook it up without an IP conflict.

Even more annoyingly it transpires its CLI commands are very different to the existing JetStream switch I have.

On the new switch, the command to enable DHCP for the management interface on the default VLAN would be:

interface vlan 1
ip address-alloc dhcp

However, since I’m planning a separate switch management VLAN and the default VLAN will be redundant I opted to leave the default configuration on VLAN 1 alone and set-up the VLANs instead, configuring a DHCP management interface on VLAN 10 only.

At this point I ran out of time, so to be continued…