Tested: VLANs in the Home Through “Dumb” Switches

Being someone who has used consumer gear for a long time, I’ve always been rather frustrated at their inconsistent or general lack of support for VLANs. Long used in corporate networks, the VLAN concept can be extremely useful for realising unusual redefinable network topologies without needing to make physical modifications to cabling or installing extra hardware.

This month, I decided that my house needed to have VLANs to prepare for the future and to make my life easier by reducing the need to run extra cabling. But most of my gear is “dumb” … so will it even work?

What is a VLAN? Why YOU might need VLANs!

On a regular home Ethernet network, all packets are “untagged” and belong to the same network. You can think of any device attached to the Ethernet network as belonging to the one giant network – to have a second “independent” network would need to have a second set of switches or cables.

The term VLAN stands for Virtual Local Area Network and is a form of partitioning that is based on insertion of one (or two in a Q-in-Q configuration) four-byte 802.11Q tag into the packet header. The presence of the tag signals the packet as belonging to a VLAN (1-4094). This allows for up to 4094 independent VLAN networks to share the same physical network (depending on the hardware)! If you want two independent networks, you can – just set each to their own VLAN number. This works as the resulting frame is still a valid Ethernet frame, just with a different Ethertype.

“So what?”, I hear you say. The applications might not seem obvious, but there are good reasons you might need this:

• Guest network separation – this is ideal for building a separated wired network segment for equipment that guests (or untrusted computers in quarantine) might use that won’t have access to your main equipment. Combine this with Virtual APs to extend the VLAN concept into Wi-Fi without needing VLAN over Wi-Fi support (which is rare). This is more flexible than the wireless-only guest network of your average consumer AP.
• Control equipment separation – IoT equipment, sensors, surveillance require stable bandwidth and high priority connectivity while needing to be protected against unauthorised tampering or scanning. Using VLANs can both protect your IoT from local attack and prevent local network devices from being compromised due to IoT vulnerabilities.
• High priority Voice over IP – for similar reasons, you might want to run VoIP over a separate VLAN to avoid performance degradation from excessive broadcast network traffic and to apply QoS prioritisation.
• Not enough cabling/cost savings – perhaps you have a distance to span where bandwidth is not an issue but needing to keep two independent networks is necessary – e.g. to extend WAN to a router and the routed local network back to the point of connection. Using VLANs would eliminate any need to run dedicated cabling for each network – if later, more cable were to be installed, VLANs could allow for bandwidth sharing of both cables in a team.

But … What About?

However, as nice and simple as this sounds, VLAN support in consumer gear is sparse and there are many ways you can break a network. Routers which aren’t VLAN aware will make creating the desired network architecture difficult – luckily for me, Mikrotik stuff is here to save the day and if not, there are also various Linux possibilities. The next problem is at the “edge”, where the endpoint gear may not be VLAN aware.

Many computers running Windows using cheaper Ethernet chipsets are only capable of running a single VLAN at a time – the main exception is Intel Advanced Networks Services capable adapters. The situation in Linux is much better, given proper driver support, but in this case, the VLAN is based on configuration, so there can be a potential for misconfiguration and security problems. There are many appliances (e.g. DVR, NVR, Gaming Consoles, SIP ATAs) that are connected to the network that have no such support.

The traditional way around this is smart switches which are VLAN aware. Smart switches would be configured with a “trunk” port where VLAN tagged frames are aggregated and forwarded and access ports which are members of one or more VLANs (depending on the unit). This scheme is known as port VLAN – the smart switch takes care of tagging and un-tagging the frames, so non-VLAN aware devices can communicate as normal. This also can enhance security when configured correctly – preventing devices from VLAN hopping by accepting only untagged frames and enforcing the tagging in a consistent manner. Unfortunately, smart switches are generally pretty expensive.

The VLAN system also doesn’t work so well with Wi-Fi adapters – while the frames are valid Ethernet frames, most Wi-Fi adapter drivers don’t support configuring VLAN IDs. Luckily, we can use Virtual APs to overcome this issue, broadcasting a separate SSID from the same radio, sharing the same channel, to access individual VLANs.

While pondering about this, the solution to the problem seemed somewhat obvious – running a pure VLAN-based network makes life with cheap equipment difficult and upgrading all my equipment was not a realistic proposition. The answer would be to run both VLAN and untagged traffic together – this is known as a hybrid trunking port. While this arrangement isn’t ideal from a security standpoint as it doesn’t protect against VLAN hopping, it should still allow me to reap the benefits of VLAN-based reconfigurability and partitioning where needed, deploying the necessary smarts only at those locations where VLAN access is needed.

There was only one catch – the 802.11Q tag adds four bytes to the Ethernet packet. This results in the regular Ethernet frame of 1538 bytes being stretched to 1542 bytes – a baby jumbo frame. These frames are in violation of regular Ethernet and consumer equipment isn’t VLAN aware so a number of possibilities can happen:

• Equipment receiving such long frames can truncate, drop or discard the frame – if this is a switch, then connectivity to the VLAN will be problematic when packets with payloads of 1497-1500 bytes are sent as FCS errors are likely in the case of truncation or packet loss in the case of drops. If this is an end device intending to access the regular network (untagged), this should be of no consequence.
• Equipment receiving a 802.11Q tagged frame can mangle the tag – this will possibly result in tagged frames being corrupted causing VLAN connectivity problems or VLAN to VLAN separation to be breached.
• Equipment receiving such long frames can crash – this may happen if there are fixed length buffers and an overflow was not tested for.

Before I can go to a VLAN arrangement, I will have to test my equipment to see how it behaves. Even for a simple question such as whether “dumb” switches would pass VLAN-tagged frames, there was no consensus online with some suggestions of “catastrophes”, so I decided it would be easier just to test it.

Testing it Out

To test out the system, I added two VLANs to my hAP ac running upstairs on the main upstairs-to-downstairs link (now a hybrid trunk carrying untagged and two VLANs). These two VLANs emerged out of two ports on the hAP ac which were configured as port-VLANs connected to a Raspberry Pi each configured with a different static IP/subnet combination and a DHCP server.

This link was first terminated into the hAP mini to bridge into each of these two VLANs via the two remaining ports (i.e. simulating a port-VLAN based smart-switch). I tested using my laptop connected into each of these ports to check that I could get the corresponding IP address as expected (i.e. network separation was correct). I then tested passing the maximum ping packet with don’t fragment to another endpoint on the two VLANs to ensure the packets would pass without errors.

The maximum ping with don’t fragment is 1472 bytes – after some confusion and lots of calculation, it seems that many people calculate packet sizes differently depending on which layer they’re talking about and whether they’re talking about the whole Ethernet Frame or not. Regardless, a 1472 byte ping packet has a 1500 byte payload due to 28 bytes in the ICMP header. From there, adding the 14 byte Ethernet Header, 4 byte Frame Checksum (FCS), 8-byte Preamble and Start-of-Frame Delimiter (SOF) and 12-bytes Interpacket Delay (IPD), we arrive at the 1538 byte “maximum Ethernet frame” figure. When a single layer of 802.11Q is added, this expands to 1542 bytes.

This initial test was successful, indicating my configuration was correct and VLAN-to-VLAN separation was maintained without disrupting the untagged network thus far. Then I connected the trunk into each of the dumb switches in my collection and connected the hAP mini to an output and repeated the experiment.

TP-Link 8-Port Gigabit v7 TP-Link 8-Port Gigabit v8 D-Link 5-port Gigabit Rev. D1 Trendnet TEG-S50g Green 5-port Gigabit Skymaster 5-port Fast Ethernet Netgear DS104 Dual-Speed 10/100 Hub

To my surprise, and my delight, all the equipment seemed to pass VLAN tagged frames without any issue – the frames came out without being truncated or mangled. This means that it is actually safe to run VLAN tagged frames through dumb switches.

For the newer Gigabit switches, this is implicit due to their support for Jumbo Frames of 9KB-16KB. A slightly oversize frame is no drama for a switch that can handle this. The only question is whether its “smarts” will cause the tag itself to be mangled, but as far as I can tell, none of mine were bothered by it – although my Skymaster seemed to be a bit slower in forwarding the frame compared to the others.

For older equipment, I expected problems but I was pleasantly surprised. Part of the reason seems to be that packet length enforcement is not that strict. In older equipment, the unit would cut off equipment that was creating excessively-long transmissions to prevent tying up the media – this was known as Jabber. However, the jabber mechanism is not precise to the length of the Ethernet frame – the shortest time from Wikipedia seems to run from 25kbits which would correspond to a frame of 3125 bytes (!!) which is still much longer than the VLAN-tagged packet. The restriction will probably be whether the clocks in these units are stable enough over the longer period to decode the complete frame correctly.

Encouraged by this, I connected the hybrid trunk to my regular switch and slept soundly in the knowledge that I have VLANs in the home, at last!

My (Simplified) Network

The above (messy) schematic shows a simplified version of the present network and the main motivation for the VLAN investigation – my current router is located upstairs on the floor to be most central to the house. This places it in a location high-enough to have even visibility of the whole house, without being so high as to interfere with others and receive interference from others. In my previous investigation – at the front of the house and at the rear, the signal was a generous -55dBm, validating its position as being optimal.

The reason for it being upstairs is because of my primary WAN being a USB 2.0 connection to a tether mobile phone – this link is necessarily limited in distance due to voltage drop and signalling. By positioning the phone up high, my signal to and from the LTE BTS is improved, ensuring I get better data rates at all times.

Add to this, my current back-up WAN is based on a long-range Wi-Fi link to a Telstra Air/Fon Wi-Fi AP which I rely on to activate new SIMs or for larger software updates to avoid exhausting my LTE service. This is a secondary network which I run on a separate subnet – running this downstairs through VLAN rather than requiring all devices connect via Vitrual AP would reduce noise on the Wi-Fi channels, reduce radiation exposure and improve reliability of the link.

Because of having some legacy gear and untrusted stuff, a third VLAN was desired just to connect this untrusted stuff for “guest” use. This way, any worms or nasties would not propagate to my main machines. But they still needed access to the internet in some way – having the ability to dynamically “cut them off” at the click of a button and/or rate limit them via queues is a definite advantage.

Then I decided I was going to run some telephony at home as well – I miss having my old Asterisk server, so a voice VLAN would be nice to reduce needless broadcast traffic from affecting my (rather underpowered) SPA112 ATA.

With all of this going on – I only had one 30m Ethernet cable to run from upstairs to downstairs. Ethernet cables are cheap but if I had to buy another three … not to talk about how ugly that would look as well! VLANs to the rescue!

In this configuration, all of the “dumb” devices access the network “untagged” as that’s the only way they know how. My RasPBX and ATA do so through an hAP mini which tags them to the voice VLAN. Because my main desktop has an Intel ANS capable card, I am able to create virtual interfaces for each VLAN and untagged LAN as well. This way, I can unbind most protocols from the VLANs and bridge them into virtual machines so I have an isolated way to access/administer/diagnose devices on those VLANs (save for a VM escape attack).

But the biggest reason to have it configured this way is to prepare for the eventual arrival of HFC NBN. As the outdoor demarcation point is now installed, it comes into the ground floor of the house in a corner. If I request them to install the HFC wallplate anywhere in the house, they will very likely do an ugly surface conduit run of the cable which is a mess. Instead, if I ask them to do a back-to-back, they might be happy (at the easy work) and the result might be a bit prettier but the CPE will now be at a bad location. So I decided that I could dedicate a VLAN to the Ethernet from the CPE by using a smart switch configured as Port VLAN (the TP-Link SG105E isn’t expensive and can definitely do this) – then it can patch using a shorter lead into my existing network on a less-ugly cable route. This can also allow for another guest network access port. Of course, now all the WAN traffic will go up the hybrid trunk/access line and most of it will come straight back down (wasting bandwidth, but there’s usually no contention – 100Mbit/s WAN + ~300Mbit/s 802.11ac file-copy is still <50% utilisation) but I can maintain just one router in the network and its good vantage point.

Alternative solutions can include:

• Ethernet over Power – but as I like listening to shortwave, I can’t handle the interference. Add to that the fact it’s expensive and slow.
• Dedicated Ethernet from here to the router – but that’s both expensive and unsightly just stringing cable around as I normally do.
• Wireless Bridge – definitely a possibility, but latency, packet loss trade-offs, additional Wi-Fi radiation and channel congestion are something I’d rather avoid
• Second Router near the CPE for WAN gateway- I do have an hAP ac² so that is a possibility, but why waste another router when you don’t need it? I don’t even need a better wireless signal!

The diagram itself is a little misleading, as the hybrid trunk is connected to a dumb switch, which really doesn’t enforce any port being a member of a particular VLAN or doing any tagging/untagging. This is both a blessing (meaning all ports can join all VLANs) and a curse (meaning all ports can inject traffic to other VLANs/participate in VLAN hopping). At home, this security compromise seems acceptable – after all guests/secondary WAN/voice VLAN users will be behind port-VLAN devices, they won’t be able to attack the untagged/other VLANs. It’s moreso that the untagged users may accidentally join a VLAN if they are misconfigured and that would be my fault entirely.

Conclusion

It’s unfortunate that more consumer gear doesn’t have VLAN support, but it can be quite useful to realise rather special network topologies and save on cabling hassle where sufficient bandwidth already exists. Discovering that tagged traffic runs just fine intermixed with untagged traffic even though older switches was a blessing, that allows me to add in VLANs to my network “transparently” – only those devices that need to access the VLAN have to be connected to an intelligent smart-switch or similar device (or have their VLAN settings configured appropriately if possible). The rest of the devices on my network operate as if nothing had changed – I haven’t noticed any strange behaviour and the switches seem to be moving traffic about as expected (no constant all-port floods, loops, etc).

With the emergence of cheaper smart switches (and the potential that other switches can be modified to gain VLAN tagging facilities), it may herald a new era where VLANs start to become more common in the home.