Once you get the hang of VLANs, it is deciding on topology and numbering (including your IPv4 and IPv6 subnetting) that is the challenging part, not the implementation. I'm old school and just think about them as Ethernet cables when doing my planning.
For carrying VLANs over WiFi, you'll either need each on their own SSID, or a tunnel. There is a good write-up of using GRE at Vlan trunk over wlan Be aware that busybox
doesn't implement ip tunnel
as configured in at least the TP-Link Archer C7 images and a custom build is required. There isn't an easy way to replace busybox
on a running system https://bugs.lede-project.org/index.php?do=details&task_id=1380 but it can be done very carefully by extracting the self-build package yourself.
I consider every WiFi device to be untrusted. For a WiFi-connected device to get access to resources on any of my internal nets, it needs to be via a secure and authenticated path; ssh or VPN.
I don't know the workings of your switch, but on the Cisco SG300-series, you can require all packets coming in to be VLAN tagged on a port-by-port basis. Combined with the VLANs associated with the port, this means that you have restricted to only the VLANs you intend to be accessed through the port (or switch-to-switch trunk, for that matter).
It's a home network and it's not all that crazy to work through. I start by thinking about resource type (UPS/power management, switches, access points, service hosts, end-users, printers,...), what services they need (DHCP, DNS, NTP,...), and how and from where they should be accessed (management interfaces and service interfaces both).
On implementing VLANs on a switch, finding the screen or CLI command to give you the information you need can be challenging. For any connected device that is VLAN-aware, you generally set that VLAN as tagged on the port. If a connected device is sending untagged packets to the switch and expecting the same in return, you need to set a PVID (default VLAN) for the port, and generally allow untagged packets for the PVID on that port. When I know the remote device only sends VLAN-tagged packets, I block untagged ingress and egress from the switch.
Maybe some ASCII art will help?
Switch port set for PVID of 100
Configured VLANS on switch are 100, 101, 102, 103
There is physically only one "wire" but, in my head, I sometimes think of them as individual wires when reasoning out how things will work.
"Dumb" remote device
- VLAN 100 is untagged
- VLANs 101-103 not enabled
Any untagged packets on the wire become VLAN 100 internally
All tagged packets are rejected (assuming you have set it that way for the port)
VLAN 100 internal <-> port <-> (untagged) on wire <-> printer
VLAN 101 internal X port <- VLAN 101 on wire <- rogue
VLAN 102 internal X port <- VLAN 102 on wire <- rogue
VLAN 103 internal X port <- VLAN 103 on wire <- rogue
"Smart" remote device, only uses VLAN 101 and 102
- VLANs 100, 103 is not enabled
- VLANs 101-102 tagged
Edit: Even when only using tagged, you generally need to set the PVID. Some switches require that it be a VLAN configured for the port.
VLAN 100 internal X port <- (untagged) on wire <- rogue
VLAN 101 internal <-> port <-> VLAN 101 on wire <-> remote server
VLAN 102 internal <-> port <-> VLAN 102 on wire <-> remote server
VLAN 103 internal X port <- VLAN 103 on wire <- rogue
"Mixed" remote device, untagged packets, as well as uses VLAN 101 and 102
- VLAN 100 is untagged
- VLANs 101-102 tagged
- VLAN 103 is not enabled
VLAN 100 internal <-> port <-> (untagged) on wire <-> remote server
VLAN 101 internal <-> port <-> VLAN 101 on wire <-> remote server
VLAN 102 internal <-> port <-> VLAN 102 on wire <-> remote server
VLAN 103 internal X port <- VLAN 103 on wire <- rogue
While I've shown the "rogue" on a non-operational VLAN, there is nothing to prevent them from snooping the wire and seeing that VLAN 101 and VLAN 102 are "valid" VLANs and configuring their own interface for one or both of those VLANs. This is where something like 802.1X port authentication comes in, if you really think you need it. For many people, password/keyed authentication to their devices is the weak link; a compromise of a "trusted" device is much more likely than an untrusted device appearing on a trusted VLAN.
For switch-to-switch trunking, I set things up with everything on VLANs, no untagged packets. In general, the more explicit you are with things, the less chances for surprise.
Speaking of surprises, make sure you know how to factory-reset your switch before you think about changing the management VLAN from its default (which you probably should do). I've messed up more than once on that myself!