Switch – VLAN Through Switch Doesn’t Work

Yes, everything here sounds correct, at least in terms of your SSIDs and VLAN requirements. How many users are you looking to support? (The performance requirements of this setup are probably the most significant aspect to be concerned with.) If you really targeting cost, and don't need to be held to "enterprise" standards, you have a few options for a L3 router. A Linux server can be setup for only a few hundred $ that would suffice, as long as the network card (even only if single interface) supports VLAN trunking to your switches (most do, especially under Linux). Another option is to use a SOHO router/access point that supports something like OpenWrt. With this route, the hardware specifications are much less than even a minimal computer, so you'll just need to be conscious of hardware capacity (CPU + RAM) for active number of connections, etc. Of the SOHO routers, something like the Ubiquiti RouterStation Pro may be your best option.

If you don't need your switches for anything other than supporting the wireless VLAN traffic - and again, if you're really looking to cut costs and aren't held to "enterprise" standards, you could double-purpose some of the same SOHO routers/access points as the the switches. Something like the RouterStation Pro or even a NetGear WNDR3800 or a D-Link DIR-825 have 4-5 Gigabit ethernet ports on a configurable switch, including VLAN support.

For a maximum of 15 users, you could most likely run the entire setup off of a single RouterStation Pro - including DHCP and DNS, with additional access points only needed if you need to cover additional distance. I'm hosting almost that off of a D-Link DIR-825. Elsewhere at a school I support, we have 10 PCs and 5+ laptops on a pair of older Linksys WRT54GLs. One is acting as the router (including DNS) and access point. The other is only a secondary access point for extended range. A separate server exists as a file server / Windows domain controller, which also handles the DHCP (though it wouldn't need to). Note that I'm not using the multi-SSID setup at the school, though again, I probably could if needed.

In terms of recommendations on what a re-purposed server should be running, I'd recommend your favorite Linux distribution. For an example, see my Ubuntu Linux Router Upgrade Project series of posts on my blog, specifically Enabling routing and NAT with iptables and Configuring LAN DCHP and Dynamic DNS under Ubuntu Linux. While my posts were written for Ubuntu, most of the instructions will apply almost equally to any Linux distribution. I'm also using the same posts on my own network today as I write this, having upgraded with each Ubuntu release every 6 months - so the notes are quite "stable".

So, you're suffering from the pretty-much-universal newbie confusion between "tagged" and "untagged" traffic. We've all been there.

The term "tagged", as applied to switch ports, means "packets that go out this port for this VLAN will have a 802.1q header saying "this is a packet for VLAN <foo>", and "I will accept packets coming into this port that have an 802.1q header saying "this is a packet for VLAN <foo>". That's great, because it's the only way you can have multiple switches all "know" that packets are on the same VLAN. It's not so great, however, when you're sending packets to a device that isn't expecting it. This most commonly happens when you're plugging in a general-purpose computer, but it can also cause problems when a switch connected to that port doesn't expect the tagged traffic.

An "untagged" VLAN, on the other hand, means "packets that go out this port for this (untagged) VLAN will not have an 802.1q header, and they will look like VLANs never happened", and "packets that come in on this port will be carried on VLAN <untagged>". In effect, this looks identical to the "dumb (VLAN-free) switch" configuration, and is typically what edge devices expect.

The question you've got to ask yourself, when thinking VLANs, is "do both devices at each end of this piece of cable know that they'll be told this traffic is part of this VLAN?". If "yes", you tag it. If not, you don't.

In your case, I'm almost certain the device you've got plugged into port 42 is not expecting VLAN-tagged traffic, and thus it's discarding those packets with a quiet "WTF?" and a raised eyebrow. You can either untag that VLAN on that port, or tell the device that it should be looking at that traffic with a VLAN perspective. End-devices can usually do that, by the way; we use it to tag VLANs all the way into our VPS servers, for instance (and tags VLANs onto Linux-based routers, firewalls, load-balancers, and some end-customer devices).