Friday, May 29, 2015

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 or, VLAN 16 could be given the subnet or, 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.


  1. Glad you find these posts of mine useful. :)

  2. Just wondering if I can use this for the case of wifi light switches. Was thinking of doing a seprate vlan for the lights, however the controller needs to live on the main vlan for control. can i do this with a layer 3 switch?

  3. The short answer is yes. The longer answer is "it depends". Different VLANs are, by definition, on different subnets. If you have a firewall or layer 3 switch that can route between the VLANs, you can do this. Keep in mind that one generally used VLANs to isolate LANs from each other, so routing them through can defeat the purpose of using VLANs in the first place.

    You should also check with the vendor of your lighting system - the switches, lights, and appliances probably need to be on the same subnet as the controller to associate properly. If that's the case, you can put the controller on the same VLAN as the lights / appliances, and then set up a routing rule for your main VLAN to route just to the controller.

    - Jason D. Hintersteiner

  4. This comment has been removed by a blog administrator.

  5. This comment has been removed by a blog administrator.

  6. This comment has been removed by a blog administrator.

  7. This comment has been removed by a blog administrator.

  8. This comment has been removed by a blog administrator.

  9. This comment has been removed by a blog administrator.

  10. This comment has been removed by a blog administrator.

  11. This comment has been removed by a blog administrator.

  12. This comment has been removed by a blog administrator.

  13. This comment has been removed by a blog administrator.

  14. Nice post... Really you are done a wonderful job. Thanks for sharing such wonderful information with us. Please keep on updating...
    Advanced & Core JAVA Training in Chennai |
    Python Training in Chennai|
    AWS Training in Chennai|
    Certified Ethical Hacking Training in Chennai|
    Linux Training in Chennai |

  15. Thank you so much for such valuable information sharing. It’s highly appreciated
    Agile Scrum Master Training in Chennai | Agile Scrum Master Training in Velachery

    GMAT Test Center in Chennai | GMAT Test Center in Velachery

  17. Thank you so much for sharing your nice post with us.. keep updating..
    GMAT Test Center in Chennai | GMAT Test Center in Velachery