VLANs: Why You Always Want to Use Them, and How They Work

VLANs, or Virtual Local Area Networks, are one of the most powerful, and one of the most misunderstood and underutilized, tools for Wi-Fi networks in the private home and small-to-medium-business space.  This post provides a pragmatic guide as to why and how you should use VLANs.

What are VLANs?

At its simplest, VLANs enable you to transform one physical Local Area Network into multiple, isolated, logical Local Area Networks.  Thus, you literally have multiple LANs with different purposes and intents that are co-located physically, without the expense of multiple sets of hardware and multiple sets of cabling.

This is extremely useful for even small network applications, especially with the growth of IoT and the proliferation of network appliances measuring and controlling our environment.

Take the "simplest" case of a private home.  Even when you only need a single AP to provide Wi-Fi coverage, there are, at least, two distinct and isolated networks needed.  First and foremost, a network is needed for the residents of the home, allowing access to all PCs, network printers, multimedia devices such as AppleTV or SONOS, IP cameras, NEST thermostats, and the like.   However, a separate network is needed by guests, as the homeowner undoubtedly doesn't want the teenage daughter's 20 closest friends staying over for a slumber party to hack any of the computers or network appliances  in the home.  In slightly more complex SMB applications, such as coffee shops, restaurants, doctor's offices, and multi-dwelling units such as an apartment building, dormitory, or hotels, there are also usually at least two distinct and isolated networks needed.   There is the network needed by the business staff for operations, such as point-of-sale, IP surveillance, access control, HVAC control, multimedia, etc.  There is also the need for the businesses' customers to be able to simply and easily access the Internet, but not have any access to any network devices used for operations.  

Generically, virtually Wi-Fi network networks need to be segmented, at least, into an operations network and a visitor network.   The requirements for who is allowed access to these networks and how they get used are quite different. 

• Operations:  Typically, access to this network needs to be restricted to authorized personnel, as it contains data that is confidential to the business and critical to day-to-day operations, especially financial and security data.  For a small network, typically a WPA2-AES Pre-Shared Key is sufficient security: the code must be known in order for the wireless client to connect to this network.  In larger setups, using 802.1x with RADIUS may be appropriate.  Once connected to the network, the client device likely needs access to other wireless devices and appliances on the network, so client devices need the ability to intercommunicate with each other.   In some environments, breaking up the operations network into multiple separate VLANs by function is appropriate, especially to separate out applications like security (i.e. cameras and access control), facilities (HVAC, lighting control), and voice over IP / voice over Wi-Fi.

• Visitors:  Also commonly referred to as a "hotspot" (i.e. independent of actual size of coverage area / number of APs), access to this network needs to be unrestricted, as the facility has no control over what devices their customers are bringing in and using.  Thus, typically no encryption is used to facilitate access, though a captive portal may or may not be appropriate to capture email / social media information, publish terms and conditions for use, and/or restrict maximum bandwidth per device.   Once connected, visitors should only have access to the Internet, and have no access to any network devices on the operations network, nor access to any other client devices on the visitor network.   You don't want a hotel guest hacking into the device in a different room.

A note on security for visitor / hotspot networks:   I keep encountering "visitor" networks that require a WPA2-AES pre-shared key.   This is actually quite pointless, and creates a false sense of security!   The logic of using a pre-shared key is that a hacker sniffing unencrypted radio frequency transmissions can intercept data traffic.   That is true.  Unfortunately, using pre-shared key encryption doesn't actually solve the problem.  A hacker that has the pre-shared key and who captures the association exchange (which is unencrypted) between a client device and an access point when it connects to the network, can use the collective information to decrypt the client device traffic.   Furthermore, most security issues on visitor / hotspot networks actually do not require sniffing the radio frequency, but rather come from the "wired side" of the network; all Wi-Fi encryption only occurs between the client device and the access point, as the access point decrypts all data traffic before passing it on to the wired network infrastructure.   If client isolation on the network is not set up properly (an all-too-common problem), a wireless hacker can simply connect to another wireless client device through the wired network.  Accordingly, the only thing that WPA2-AES pre-shared key adds to your network does is increased overhead on the staff, who have to give out the passphrase to all of the visitors.  If you want to remain secure when using a hotspot / visitor network,  make sure you are using application level security, such as https for web surfing and SSL for your email service. Personal or corporate VPNs are also eminently appropriate and effective. 

Many consumer wireless router appliances, such as the EnGenius ESR series, and enterprise wireless access points, such as most EnGenius APs in the EAP / ECB / ENS / ENH / EWS series, come with the ability to set up a "guest network" with a separate subnet and DHCP range.  The access point therefore creates a Layer 3 (IP) barrier between the guest network and the operations network to isolate them from each other.   Using this feature, however, is only appropriate for single AP networks.  On networks consisting of multiple APs, this configuration prevents roaming between APs since each AP is creating a separate standalone guest network.  Any client attempting to roam on the “guest network” will have to re-establish a Layer 3 connection, thus interrupting any streaming applications.  Thus, on multi-AP networks, VLANs should always be used to provide visitor / guest networking.

How do VLANs work?

Client devices don't know, and generally shouldn't know, anything about the VLAN configuration of a network.   Accordingly, all VLAN configuration is done on the network router, switch(es), and access point(s).  When a client device sends data, each packet is "tagged" as it enters the network so it can be routed to the correct destination, similar to the way your luggage is tagged when you check it at the airport, to make sure it is loaded on to the correct plane(s) to travel with you and is retrieved at your destination.   When the data reaches its intended destination, the tag is removed, which is commonly referred to as either "untagging" or "stripping the tag".   

In networking, the VLAN tag is a 4 byte element inserted into the MAC header of the packet.  This element contains a 12 bit number indicating the VLAN ID (or VID), meaning that, in theory, a network can have 2^12 or 4096 tags.  The all zero and all one tag (i.e. VLAN 0 and VLAN 4095) are not used per the 802.1q specification.  Furthermore, VLAN 1 is reserved for "untagged traffic", meaning that any data traffic in a network that does not have a VLAN tag is considered to be on VLAN 1.  This is also why all switch and access point VLANs are defaulted to VLAN 1.

By default, each port on a switch will drop VLAN traffic, so any VLAN traffic that is allowed through a switch port must be explicitly defined in the configuration.  Trunk ports are used to interconnect switches (and access points), where each VLAN in use on the network is explicitly defined as a tagged VLAN, meaning that the switch will pass traffic on that VLAN without touching the VLAN tag.

The tagging / untagging mechanism in switches and access points are a bit different between a wired client and a wireless client, but functionally they are identical:

• Wireless:  A wireless client associates to a particular SSID, and in the configuration of the access point, the SSID is associated with a particular VLAN.   All traffic coming from a wireless client is tagged with the VLAN ID associated with the SSID.  Similarly, the access point strips the tag associated with the SSID for all data traffic being transmitted to a wireless client.  Thus, from the perspective of the switch, all traffic coming from or going to an access point is tagged.
  
• Wired:  A wired client is connected to a particular port on a particular switch.   This port has two settings associated with it, which unfortunately are commonly put on different screens.  The first is the PVID.  This setting indicates the VLAN ID that should be tagged onto all traffic coming into the port (i.e. from the wired client).    Since each port has all allowed VLANs explicitly defined on it, an untagged VLAN can be defined, such that any traffic on that particular VLAN gets its tagged stripped before the traffic leaves the port.   By definition, a wired port connected to a client can have only one PVID and should have only one untagged VLAN, and these two should match in order for the connected wired client to communicate in both directions on that VLAN.

The router configuration similarly becomes a bit more complex.  Each VLAN on the network is considered to be a sub-interface of the LAN interface (since multiple VLANs exist on the same physical wire / NIC).   Thus, instead of defining an IP address, subnet, and DHCP range for a single LAN, each VLAN is treated as a separate LAN, and requires an independent subnet, IP address, and DHCP range.   By convention, some people like matching the second or third octet of the subnet to the VLAN ID.  For example, VLAN 8 could be given the subnet 10.8.0.0/16 or 192.168.8.0/24, VLAN 16 could be given the subnet 10.16.0.0/16 or 192.168.16.0/24, etc.   These settings are independent, so no correlation between the VLAN ID and the subnet is required, but it is often convenient. 

Typically, VLANs are used to keep the various LAN subnets isolated, so the router is generally just doing WAN to VLAN routing.   Cross-VLAN routing can be done in specific instances, and usually requires explicit rules to be set up to allow particular exceptions.   One common example would be a hotel with a printer in the lobby that they want both staff and guests to be able to use.   This printer could be placed on the visitor VLAN, and router rules can be defined to route traffic from the operations VLAN to the printer on the visitor VLAN.  In such a case, however, it is often simpler and cheaper to just buy two printers.

What's a Management VLAN, and should I use it?

Just as your operations and your visitors are put on two (or more) VLANs to separate the network traffic, it is best practice to use a separate VLAN for the web and CLI interfaces for your network router, switch(es), and access point(s).   This way, no users on any user VLAN can access (and therefore hack) your network equipment.   The management VLAN, therefore, is the VLAN for your network equipment.   

By default, all network equipment comes with the management VLAN set to 1, and all managed and smart switches are configured such that every port is PVID 1 / untagged VLAN 1.    Strictly speaking, if your operations users and visitor users are on their own VLANs, then the LAN is isolated from the VLAN users and acts as a separate VLAN (i.e. VLAN 1).   However, any user connecting to a misconfigured access point or a non-configured switch port can access your network equipment.  Therefore, it is best practice to explicitly define a VLAN for management and configure all of the network equipment to require traffic to be on the management VLAN in order to access its configuration. 

Can I get myself into trouble using VLANs?

Absolutely.   VLANs are a powerful tool, and are quite easy to misconfigure.   The usual problems encountered with VLANs are the following, along with some guidelines for avoiding and/or troubleshooting:

• Device is on the wrong VLAN:   This is usually due to traffic being put on to the wrong VLAN as it enters the network.  Make sure your SSID settings and PVID / untagged VLAN switch settings are correct.  Fortunately, this is usually fairly easy to catch, especially if your client device is configured for DHCP.   One look at the IP address on the client device will indicate if it is not getting a DHCP address, or is getting a DHCP address on the wrong subnet.  For static clients, an arping or nmap on the wrong VLAN will reveal the presence of the client.

• Data traffic doesn't flow:   This is usually due to either traffic being put onto the wrong VLAN as it enters the network, or switch ports not being properly and explicitly configured to pass traffic on that VLAN.  Remember that all network equipment ports on a switch, defined here as ports connected to either the router, backhaul to other switches, or access points, should be trunk ports and be configured for tagged VLANs for all VLANs used in the network, including management VLANs.  All ports connected to client devices and/or network appliances should only be configured for the PVID / untagged VLAN that the client should be connecting to. 

• Lose access to network configuration:  This is virtually always a VLAN mismatch between the PC being used to configure the network devices and the management VLAN set up on the device.   Management VLANs should generally be configured last; once you configure a network device to use a particular VLAN, you will typically lose access to that device until changing the port of your PC to be on the same VLAN as the management VLAN.  If you have a switch configured to be on management VLAN 4000, but none of the switch ports are configured for tagged or untagged access on VLAN 4000, you are cut off from the switch and have no way to access the configuration, short of a serial interface or a hard reset.   I always advise that each network switch have one port designated as a management port, and that it be configured to be PVID / untagged VLAN on the management VLAN.  

VLANs are a powerful tool, and should be an integral part of all of your Wi-Fi network designs.

How Operators can make Hotspots and Public Wi-Fi Safer

There are numerous articles, papers, and books that decry the lack of security at public hotspots and other networks that are open / quasi-open to the public, such as the Wi-Fi in hotels.   There have been several incidents in the past where some celebrity gets hacked and has their photos and emails downloaded by nefarious parties.

Unwaveringly, however, the "solution" seemingly endorsed by the Wi-Fi industry is always to not trust the hotspot and put the burden on the user:

-        Disable automatic login

-        Turn off file sharing

-        Forget the network

-        Use encrypted applications (e.g. https, SSL)

-        Maintain up-to-date firewalls, anti-virus, and malware software, along with OS security patches

-        Use a corporate or personal virtual private network (VPN)

See a popular infographic circulating around the Twittersphere.

While all of these things are certainly good advice and "best practice", the message of the industry is that the burden of data security is pushed onto the user.   This is flawed for several reasons.   Most IT professionals have difficulty keeping their own OS patch, firewall, anti-virus, and malware deployments up-to-date without expensive programs or services to do it for them automatically.  To expect non-tech savvy users to both do this and keep on top of this is simply unrealistic.   Secondly, while there are lots of software packages available on PCs and laptops for firewalls, anti-virus, anti-malware, and VPN client software,  the selection is quite limited or even non-existent for the smartphones and tablets, which are primarily the devices used on hotspot and public Wi-Fi networks.  Most importantly, however, this implicitly absolves the hotspot / public Wi-Fi operator of any responsibility or ownership of security issues.

While users do need to have some level of personal responsibility and practice common sense, anyone who has ever done any serious work in IT security will tell you that data security is about “defense-in-depth” and must be considered at every level of the network architecture.  Security is something that has to be considered and configured for every device in your network, at every layer of the OSI stack.  This is a belt & suspenders approach, to ensure that a vulnerability to an attack at one layer can get stopped at the next. 

Accordingly, there are simple measures that can be taken in the configuration of a hotspot / public Wi-Fi network by the operator that serve to heighten security and make users safer.  In essence, there is an intrinsic requirement on any hotspot or public Wi-Fi network that clients should be isolated from one another.  If they cannot see each other, they cannot hack each other!  This requirement is always there, but it isn't always acknowledged or realized.  Client devices on a public Wi-Fi network simply do not need to intercommunicate with each other.   So why let them?   

Courtesy: http://i0.wp.com/education.healthcaresource.com/wp-content/uploads/2013/11/iStock_000006853763XSmall.jpg?zoom=1.5&w=325

(Yes, there may be things like publicly accessible printers / TVs, but that can be easily handled as an exception with proper network design and configuration.)

The biggest objections to implementing security, of course, is that it is a PITA for both users and operators and costs too much in equipment and labor.  This is really just an excuse, as Wi-Fi and wired network equipment has been around for many years that have security capabilities built in, if you know how to use it.  Furthermore, such equipment doesn't need to be high end – virtually any enterprise-grade router, switch, and access point has everything you need to build a secure public Wi-Fi network. 

Guideline #1: Use enterprise-grade networking equipment.  Consumer routers and APs are designed for consumer environments, not hotspots and public Wi-Fi networks.  Stop using consumer gear in these environments!  There are plenty of low cost enterprise-grade access points on the market, such as the EnGenius EAP and ECB series of APs.  These models cost nearly the same as their consumer counterparts, and include all of the necessary features built in to operate simple and safer public Wi-Fi networks. For more elaborate networks consisting of several APs, a low cost enterprise-grade managed solution, such as the EnGenius Neutron series, is appropriate because of the additional monitoring and management tools.

Guideline #2:  Don't mix and match APs from different vendors.  While different models of an AP may be needed to accommodate different environments (e.g. indoor vs. outdoor), avoid mixing APs from different vendors.  This is primarily not a functionality restriction, but a pragmatic one.  Aside from the name / location of the AP, its IP address, and its static channel settings, all of the APs should generally be configured exactly the same way.  Mixing and matching APs from different vendors precludes the ability to match configurations.  Two APs from two different vendors set up seemingly in the exact same way will perform differently.

Guideline #3:  Change the default passwords and SNMP communities.  This one should be obvious, but I keep seeing it time and time again.  Many devices will allow for the creation of read-only accounts, so that device settings can be viewed but not altered.  This is generally a good idea if multiple people "need" access to the equipment.  As for SNMP, it can be a very powerful management tool, but can also be easily abused by hackers.  If you are using SNMP, change the default community strings.  If you aren't using SNMP, turn it off!

Once the proper enterprise equipment has been selected, how should it be configured?  Remember that the goal is to keep clients isolated from each other.  This needs to happen at every level of the network.

Guideline #4:  Enable client isolation on your public SSID.  This is usually a check box labeled either "client isolation" or "station isolation" that, when enabled, prevents clients on the same AP from intercommunicating.  Some APs also have a "L2 isolation" feature which prevents clients on different APs (but the same SSID) from intercommunicating.  If your AP has that feature, use it.  If not, don't worry, because this level of protection can also be implemented on a managed switch.

Guideline #5:  Use VLANs.   If you have multiple types of users in parallel (e.g. guests, staff, security, IoT appliances, etc.), this is a necessity.  However, even in a hotspot environment with only one type of user access, it's still a great idea.  Why?  VLAN implementations generally require the use of a management VLAN for network equipment, which puts your network equipment on a separate virtual network from your users.  But you get this benefit even when you aren't using a management VLAN per se, as the network equipment stays on untagged VLAN 1 while the users are all placed on another VLAN.  Result?  Wi-Fi users cannot see or access the network equipment.

So far, the discussion has centered on the APs, but switches and routers are also a critical part of this equation.

Guideline #6:  Use managed (or at least smart) switches.  First and foremost, the switch has an IP address, meaning that the switch can be monitored remotely and accessed to run diagnostics when (note I don't say "if") needed.  Smart and managed switches also support VLANs, so will be necessary for any network deployment implementing them.  Some switches also come with port isolation features, which prevent communication between client ports (e.g. access points) and only allow clients to communicate with backhaul ports.  I personally like using managed switches, as most smart switches don't support implementing access control list (ACL) rules.   ACL rules are an extremely powerful feature to make each port on the switch act like a firewall, capable of allowing or denying traffic on each port based on characteristics like its source or destination IP address / subnet.  Why is this useful?  It can be configured to prevent devices on the same subnet from talking to each other (with exceptions for your router and DHCP server).   I'll be posting a separate blog in the near future with a detailed example of how to configure ACL rules for various scenarios.   As with APs, SNMP communities should be changed or SNMP disabled if you're not going to use it.

Guideline #7:  Use an enterprise router / firewall.  Again, this doesn't need to be a multi-thousand dollar appliance, but don't use a consumer NAT router or the garbage typically provided by the Internet service provider.  There are several devices starting under $200 which are appropriate, with cost generally correlated with capacity.  At a minimum, your enterprise router  needs to support VLANs, DHCP, and DNS resolution.  Typically, you will also want to include Unified Threat Management (UTM), and you may or may not also want application filtering (to prevent torrents) and/or content filtering (to prevent users in a public place from surfing inappropriate sites).  Implementing bandwidth restrictions by client device is also an option on some routers, to ensure that no single user can consume all of the bandwidth you are providing. 

Guideline #8:  Use captive portals.  I know a lot of Wi-Fi engineers who hate captive portals, but they are an absolute necessity in providing public and semi-public access.  Captive portals let you identify what devices are on your network and how much bandwidth they are consuming.  This is not only required by law to be CALEA compliant, but it is just a good idea for (quasi-)public networks to have some knowledge over who is connecting to your network and how much bandwidth they are consuming.  Additionally, captive portals always require acceptance of the “terms of service”, an annoying amount of legalese that nobody ever reads, but this serves to protect the operator in the event someone connects on your network and tries to hack someone else on the Internet.   Captive portals can also be a useful marketing tool: the splash page is great real estate, and many appliances enable login with social media credentials, giving the operator a list of validated contacts for future e-marketing campaigns. 

Some may have observed that I have not said anything about using WPA2 encryption.   As the 802.11 standards are currently defined, the use of an encrypted Wi-Fi signal is useless in a public Wi-Fi environment.   By definition, all clients are BYOD, so the use of WPA2-Enterprise (i.e 802.1x with a RADIUS server) is simply impractical.  Furthermore, using WPA2-Personal (i.e. a pre-shared key / passphrase) just becomes an overhead nightmare for the operator, as it needs to be posted publicly and/or people keep asking for the passphrase.  While in WPA2, an AP does establish a unique set of encryption keys with each client, there are packet sniffing tools readily available that can decrypt data packets when provided with the WPA2 passphrase.   Amazingly, there are so many “public” hot spots in restaurants, doctor’s offices, and the like where WPA2-Personal is used, but this only serves to make the users that can get online “feel” safer without actually doing anything to address security – data cannot be guaranteed to stay encrypted, and a well-advertised WPA2 passphrase won’t prevent man-in-the-middle attacks.  More importantly, encrypting the wireless traffic between the client and the AP is pointless if client isolation is not enabled – two clients with encrypted connections can still see each other on the “wired” portion of the network, which is not encrypted at the MAC layer.    Hence, users should still be operating encrypted applications utilizing https and SSL, which do the encryption of the data all the way up to the application layer.

The security of public Wi-fi networks requires a defense-in-depth strategy.  There are relatively simple configurations and choices that operators of hotspots and other public Wi-Fi networks can do to make their networks intrinsically safer for their users.   In combination with user common-sense, public Wi-Fi networks need not be unsafe environments for people to access the Internet.