published on in Homelab

Homelab 101: network planning

Planning a network of any size is always a good idea before you dive in. Because we have a learning environment inside a “production” network, some planning goes into preventing one from impacting the other. The interesting challenge here is in keeping the cost down. I don’t have the budget for two separate networks, so the two environments will intersect at more places than would be ideal.

One of the major instruments in the separation of networks is the VLAN, or Virtual LAN. This is a construct that lives on Layer 2 of the OSI model: the link layer. In order to make effective use of VLAN’s preferrably every switch in your network should have support for them. And by support I mean the ability to read and write the VLAN tags and act upon them. What you’re looking for is a ‘smart’ or ‘managed’ switch. Just about any cheap ‘dumb’ switch nowadays will pass your VLAN-tagged packets unscathed, but you won’t be able to do anything useful with them.

VLAN setup

I created a number of VLAN’s on my gateway device, the APU2c4 running OPNSense.

  • VLAN 10: The user network. Every end-user device such as laptops, desktops and phones gets connected here.
  • VLAN 20: Guest network. Visitors get to use this VLAN that’s published as an open WiFi network with some limitations.
  • VLAN 100: The infra network. All physical devices are connected to this as the default VLAN on one of their physical ports.
  • VLAN 200: The apps network. I host applications for internal use inside their own VLAN.
  • VLAN 250: Internet services. Similar to 200, but for internet-facing “public” services. They get isolated because of their increased security threat profile.

Each of these VLAN’s represents a virtualized physical network. It’s as if my in-house cabling wasn’t configured as one network, but five. To do this without VLAN’s, my gateway device would need at least six ethernet ports. It has only three, of which one is currently not even used (yet). The use of VLAN’s decouples the physical configuration of the network from its logical configuration.

The gateway

The OPNSense firewall sits in the middle of all of this. It serves as the default gateway for each of these networks, taking the first IPv4 address in each of the networks as follows:

  • VLAN 10:
  • VLAN 20:
  • VLAN 100:
  • VLAN 200:
  • VLAN 250:

You’ll notice that the third octed of the IPv4 network address follows the VLAN numbers. That’s entirely optional and there is no technical relation there whatsoever. I could configure VLAN 10 with network if I wanted and it would still work. The way I did it here allows me to see in which VLAN an address lives without looking it up. It’s a trick that works as long as you have less than 255 VLAN’s, and you’d be hard-pushed to find even a well-designed enterprise network with so many VLAN’s in active use.

What I’ve achieved here, is separation of networks. Machines within the same VLAN can communicate freely. The switch will short-circuit the traffic as needed so the gateway device won’t form a choke point.

Traffic between different VLAN’s must travel across the gateway and be routed by it. This gives me the option to do firewalling at the gateway. By default, no traffic at all is allowed to cross the boundary between two VLAN’s and I build rules up from there. This results in a secure network where traffic only flows where it has a valid reason to flow.

The switches

The Cisco SB300 28P switch is my core switch. It sits very near to the point where the ISP’s fiber enters my home and where all ethernet cables from the different rooms of my house are bundled.

It has VLAN 100 (the infra network) defined as the default VLAN on all ports that are active and link up to a server-like device. Right now that’s the gateway device itself, the two WiFi access points and the uplink port that feeds into my homelab rack. The other ports lead to rooms in my house and have VLAN 10 as their default port VLAN. Any device you plug in there gets placed in VLAN 10.

The other VLAN’s are added to ports as “tagged/trunked” VLAN’s as needed. The uplink port to my rack gets VLAN’s 200 and 250 added to it. The WiFi access points get tagged VLAN’s 10 and 20 and that’s it.

The TP-Link switch in my rack passes VLAN’s 200 and 250 through as tagged on each of its active ports. It also, very sneakily, has VLAN 50 (and network configured on it. This connects my NAS and the backup NAS together and my backups pass through that every night. Nothing in the world has any business interfering with any of that, ever. Could I have just connected a cross-cable between them? Yes, but I don’t have the LAN ports on the NAS devices available for that.

The Infra VLAN

The Infra VLAN is there to allow my worker nodes, the Raspberry Pi’s in this case, to access my NAS in an unimpeded manner. The Pi’s each have ISCSI storage mounted on them and that’s something I want to keep separate from “business” traffic. The Infra LAN could have been called Storage as well, but I’m sticking with this more generic name to accommodate any new tasks in the future.