Using VLANs with EnGenius APs and Switches

Written by: EnGenius Technologies, Inc.

 

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 wireless and wired LANs with different purposes and intents that are co-located physically, without the expense of multiple sets of hardware and multiple sets of cabling.

 

 Figure 1:  Conceptual hardware view of VLANs.

 

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.

 

Even in the simplest case of a private home, where only one AP is needed to provide Wi-Fi coverage, there are generally, 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 their teenager's friends to hack into any of the computers or network appliances in the

 

home. In 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 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 For a small network, typically WPA2 Personal (i.e. an AES encrypted pre-shared key or passphrase) 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 called a "hotspot", access to this network needs to be unrestricted, as the facility has no control over what devices their customers are bringing in and Thus, typically no encryption is used to facilitate access, though a captive portal may or may not be used to capture email / social media information or set out terms and conditions. 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: Many SMBs tend to provide a "visitor" network that requires a WPA2 Personal. This is actually quite pointless. Doing this only creates more overhead for the staff, who have to provide the customers the passphrase, and it only 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. While this is technically true, using standard WPA2 Personal doesn't actually solve the problem. A hacker, possessing the passphrase and who captures the unencrypted association exchange between a client device and an access point when it first 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 Personal adds to your guest network 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, there is no mechanism to allow roaming between APs, since each AP is creating a separate and functionally isolated 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 all 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 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 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 must have 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. The VLAN ID and the subnet settings are independent, so no correlation between the VLAN ID and the subnet is required, but it is often done for convenience.

 

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 on the firewall 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 would be placed on a dedicated “shared device VLAN”, and router rules can be defined to route traffic from either the operations VLAN or the visitor VLAN to the shared devices VLAN.

 

Note that most consumer routers, including routers supplied by cable and telco companies, do not support VLANs. EnGenius does not manufacture an enterprise router that supports VLANs. EnGenius switches and access points are all Layer 2 devices, and will integrate easily with any standard enterprise-grade Layer 3 router.

 

What's a Management VLAN?

 

Just as a facility’s operations and visitors are segmented 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 the network equipment, such as the network router, switch(es), and access point(s). This way, no users on any internal user VLAN can access (and therefore hack) the 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 Make sure all SSID settings and PVID / untagged VLAN switch settings are correct. Fortunately, this is usually fairly easy to catch, especially if a 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 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 or equipment: 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  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. It is advisable that each network switch have at least one PoE 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.

 

Configuring a Network with VLANs and a Management VLAN

Since switches and access points in their default configurations are on management VLAN 1, it can be tricky to implement a management VLAN on a network and have all of the switches and APs accessible on the management VLAN. (Think performing brain surgery while dancing in a mosh pit.) If the process is not performed in the correct sequence, the risk is run of completely losing access to some or all of the network equipment.

 

This section provides step-by-step instructions for implementing VLANs and a management VLAN on a Neutron network, though the process is identical for standalone APs.

 

Step 1:  Define the VLANs, including the management VLAN, on the router

Each vendor’s router will have differences in the configuration procedure. In general, under LAN interfaces it is possible to define VLAN interfaces under a primary LAN interface. The definition of each VLAN will require defining a unique private IP and subnet mask, as well as appropriate DHCP ranges.

 

If adding a management VLAN to an existing network, it may be necessary to change the IP scheme of your switches and access points. It is usually simpler and less error-prone to change the IP scheme of your primary LAN interface on the router (which will ultimately not be used), and then reassign the existing scheme to the VLAN ID being used for management. If you do need to change the IP address scheme on your network equipment, then make sure your configuration PC is setup for both the old and new IP address ranges, and change over the IP addresses at the VERY END of the process, once all of the equipment is shifted to the management VLAN.

 

 

Step 2:  Define the VLAN on the switch / EWS controller and define a management PoE port

It is best practice to define at least one management port defined for a technician to be able to access the network equipment at a site. This port can also be used to provision a new access point on an existing network. (If you are doing this locally, you may need two management ports: one for your PC and one for the access point.)

 

Make sure your configuration PC is NOT connected to the designated management port at this point. The designated management port should be empty.

 

The VLAN needs to be defined and labeled as management on the switch (or switch side of the EWS controller) on the VLAN   802.1Q screen.  It should be tagged on all equipment backhaul ports (i.e. APs

 

and switches) and blocked on any wired access ports for other VLANs. At least one port should be designated as a “management port”, which will be set to untagged. Typically, a designated management port will not have any other VLANs defined on it (i.e. it will only allow traffic on the management VLAN).

 

In the example below, VLAN ID 4000 is the management ID, and the management port is set to port #1.

Figure 2:  Switch VLAN   802.1Q screen defining the management VLAN ID 4000 with untagged on port 1.

 

On the VLAN   PVID screen, select the same port(s) as above set to the management VLAN ID untagged and set their PVID to the matching value.

 Figure 3:  Switch VLAN   PVID screen defining the management VLAN ID 4000 with untagged on port 1.

 

This process must be repeated for every managed switch in the network. It is advisable to pick the same port on each switch as the management switch if possible.

 

If adding a new access point to an existing network with a management VLAN defined, then EITHER pre- provision the AP by connecting it to the designated management port OR you must configure the port connected to the new AP as a separate management port that is untagged / PVID on the management VLAN.  Any other tagged VLANs (e.g. for SSIDs) will not matter and can be left in place.

 

Step 3:   Add access points to your network

At this point, all access points get added to the network and associated with AP groups. The switch ports connecting to the access points must all be set to untagged VLAN 1, and tagged on the management VLAN ID as well as all VLAN IDs being used with SSIDs.

 

If the APs are going to be part of AP group(s), then the management VLAN needs to be set in the AP group under “Advanced Settings”. All other AP group settings (e.g. radio and WLAN settings per band) should be made at this point as well.  For standalone APs (e.g. Electron series), there is typically a “management

 

VLAN” tab in the GUI, but all other settings should be saved and applied to the access point before setting the management VLAN.

If adding a management VLAN to an existing network, then the AP group(s) only need to be updated to enable the management VLAN ID in Advanced Settings.

 

Once the management VLAN is applied and the AP group settings are fed to the access points, you will lose connectivity to the access points in this AP group and they will show offline in the EWS controller. This is expected behavior.   You will regain access to the access points in a later step.

 

Figure 4: AP Group --> Advanced Settings.  Enable and set management VLAN.

 

If adding a new access point to an existing network with a management VLAN defined, since the new AP is connected to a management port, it is put on the management VLAN by the switch. The AP will be detected by the EWS controller and you will simply need to add it to the existing AP group. Once the configuration is applied to the new access point, the AP will be offline. If the AP was provisioned in the permanent management port, wait two minutes (to ensure the configuration was uploaded and the AP rebooted) and move the AP to a pre-configured AP backhaul port.  If the port VLANs were changed to set it to untagged / PVID on the VLAN ID, then change the configuration of that port again on the VLAN screens to make it tagged on the management VLAN and untagged / PVID on VLAN 1.

 

 

Step 4:   Apply the management VLAN to your switches and EWS controller

At this stage, all of the access points are configured to be on the designated management VLAN, but the EWS controller / switch and any EGS switches are still on VLAN 1. You must now configure your switch(es) and controller to be on the designated management VLAN. This can be done by going to VLAN   Management VLAN on the switch (or switch side of EWS controller) and setting the management VLAN to be your designated VLAN ID from the pulldown list.

 

It is recommended that you change the switches from the extremities of your network to the core of the network, assuming your configuration PC is plugged into your core network switch.

 

 

<figure TBD>

Figure 5: VLAN   Management VLAN. Select the correct VLAN ID from the pulldown list (only VLANs already defined on the VLAN 802.1Q screen will be on this list).

 

Once the management VLAN is applied to the switch(es) and EWS controller, you will lose connectivity to them. This is expected behavior. You need to plug into the designated management port to re- establish access.

 

Step 5:  Plug in your laptop into the designated management port

At this stage, all of the access points, switches, and controller are configured to be on the designated management VLAN. The configuration PC, however, is plugged into a port putting it on VLAN 1. Move the Ethernet cord to the designated management port to put the configuration PC also on the designated management VLAN. Once the cable is shifted over, reload the browser window and log into the EWS controller.

 

All APs, switch(es), and the EWS controller will be accessible. APs should now show up online in the EWS controller. When connecting directly into a switch on the local network, the management port MUST be used for the configuration PC in order to access the equipment.

 

Check out EnGenius Forum about similar topic: 

http://community.engeniustech.com/topic/1059-using-vlans-with-engenius-aps-and-switches/