Showing results for 
Show  only  | Search instead for 
Did you mean: 

vWLAN General Deployment Guide

vWLAN General Deployment Guide


  1. Introduction
  2. Design Considerations and Limitations
  3. Planning and Preparation
  4. Implementation
    1. Locations and Location Groups
    2. Services and Service Groups
    3. Destinations and Destination Groups
    4. Roles
    5. Authentication
    6. Service Set Identifiers (SSIDs)
    7. AP Templates
  5. Additional Configuration Considerations
    1. Domains
    2. Configuring a Basic Role to Allow All Traffic
    3. Automatically Removing Idle Client Connections
  6. Conclusion
  7. Useful Links


This document will act as a general deployment guide for vWLAN and should be considered as a supplement to the vWLAN Administrator Guide. Adtran recommends configuring each item in the order shown below. Following this general deployment outline will ensure a successful vWLAN installation.

  1. Planning and Preparation
  2. Locations and Location Groups
  3. Services and Service Groups
  4. Destinations and Destination Groups
  5. Roles
  6. Internal Authentication
  7. External Authentication
  8. Captive Portal Forms
  9. Service Set Identifiers (SSIDs)
  10. AP Templates
  11. Domains

This guide assumes that vWLAN is already accessible via IP through the administrative interface. If you need assistance deploying vWLAN in VMware, please consult the documentation. Please read the vWLAN Hardware Appliance (1st Gen) Quick Start Guide for assistance with the physical vWLAN hardware appliance.  It is best practice to activate Bluesocket Access Points after configuring vWLAN. However, if you need assistance with activating Bluesocket Access Points, please view the .

Design Considerations and Limitations

For the initial configuration, Adtran recommends configuring Locations prior to connecting any Bluesocket Access Points (BSAPs). This is due to the nature of location discovery which will be described in more detail later.

In most deployments, VLAN limitations will not be an issue. One often overlooked VLAN parameter is the number of hosts allowed in the VLAN. This guide does not aim to describe subnetting in detail, but note that the size of the layer 3 networks will affect how many hosts are allowed as well as how much broadcast traffic may be seen in the network. Excessive broadcast traffic can introduce problems. These boundaries also help isolate multicast traffic. For more information, please consult the .

Multi-tenant functionality was released in vWLAN version 2.2. Adtran currently suggests limiting vWLAN to fifty (50) domains and 1500 APs. Please consult the vWLAN releases notes for your version to verify this limit.

Planning and Preparation

It is essential to decide how users will be grouped and what criteria these groupings will be based on. The vWLAN provides a few different segmentation options.

  • Locations
  • Roles
  • SSIDs
  • Multi-tenant Domains

Locations in vWLAN are the various networks that the APs can support. Locations are directly related to layer 3 network addresses and masks as well as any VLAN tag which may be associated with these networks. For example, the network might exist with a VLAN tag of 10. This would translate to vWLAN as a Location.

Note: If vWLAN and the BSAPs are separated by a firewall, please consult the to verify that all required ports are open between the BSAPs and vWLAN.

The SSID is probably the most visible aspect of the wireless network. It is the logical wireless network name that end-users are looking for when they open the wireless utilities on their devices. An SSID can be up to 32 ASCII characters in length (including whitespace). Often times multiple SSIDs will exist within the same organization. For example, it is common to use separate SSIDs for expected users and guests.

Note: As a general recommendation, Adtran suggests using no more than eight (8) SSIDs per radio. Each BSAP has two radios: one for 2.4 GHz (802.11b/g/n) and 5 GHz (802.11a/n).

The Authentication and Cipher on the SSID will determine what information is required from the user in order to connect, and it may determine whether or not the traffic is encrypted over the air. SSIDs must be configured with an Authentication type: Open System (no authentication), Shared Key (WEP), or various forms of Wi-Fi Protected Access (WPA). WPA includes both preshared key (WPA-PSK and WPA2-PSK) or 802.1X (WPA or WPA2). The Cipher types are dependent on the Authentication type. Wireless Local Area Network (WLAN) authentication types and ciphers are explained further in documentation listed in the Useful Links.

From the end user’s point of view, a smooth experience generally involves understanding the steps it takes to get connected and having access to the resources they need. A vWLAN administrator should understand the order of operations and precedence as follows in order to assist clients as they access the wireless network.

  1. SSID Authentication (open authentication, preshared keys, 802.1X user credentials)
  2. MAC Authentication
  3. Wild Card MAC Authentication
  4. SSID Default Role
  5. 802.1X Matched Attribute
  6. 802.1X Default Role
  7. Local Web Based Authentication
  8. External Web Based Authentication

The last consideration is whether or not multiple domains should be used in vWLAN. Each domain will behave as an independent vWLAN system, all hosted from the same server location. This provides granularity in user tables and administrators, and it also helps to isolate the impact of configuration changes and troubleshooting. Typical use cases include business parks where each business has its own autonomous wireless network, large school districts, individual college dormitories, and hosted vWLAN cloud solutions.


Locations and Location Groups

Adtran suggests configuring location-related items in the following order before bringing the BSAPs online or applying changes to the AP.

  1. Layer 3 (network) interfaces
  2. Layer 2 interface (VLAN)
  3. Trunk ports for 802.1q support
  4. DHCP scope for the VLAN
  5. Locations in vWLAN

A location in vWLAN will be directly related the network address, mask, and VLAN tag (when applicable) of networks that exist in the LAN. In vWLAN, Client traffic is policed and forwarded at the AP; the traffic is not tunneled to vWLAN. For this reason, it is important to understand how locations are related among the LAN configuration, the BSAPs, and vWLAN. Locations are activated in vWLAN when an AP successfully receives an IP address via DHCP. More information on location discovery can be found in the Useful Links.

The layer 3 interface could be a router interface or a subinterface, or it might be a logical interface on a layer 3 switch. For example, the subinterfaces on a Netvanta router might be configured as follows.


interface eth 0/2

  encapsulation 802.1q

  no shutdown


interface eth 0/2.1

  vlan-id 1 native

  ip address

  ip access-policy Management

  no shutdown


interface eth 0/2.10

  vlan-id 10

  ip address

  ip access-policy Faculty

  no shutdown



Below is an example of the same IP interfaces above, but on a Netvanta layer 3 switch as opposed to a router.


interface vlan 1

  ip address

  no shutdown


interface vlan 10

  ip address

  no shutdown



The layer 3 interfaces will generally reside at or near the core of the network. Each additional layer 2 device in the distribution or access layers will still need to have logical interfaces (VLANs) created if the equipment is required to support the networks. Further, the uplink ports between the router(s), switches, and BSAPs will need to be configured to support VLAN tagging (802.1q). The switchport example can apply to switch-to-switch uplink ports, switch-to-router uplink ports, and ports where the BSAP is connected.


vlan 1

  name "Default"


vlan 10

  name "Employee"


vlan 24

  name "Guest"


interface gigabit-switchport 0/1

  switchport mode trunk

  switchport trunk native vlan 1

  switchport trunk allowed vlan all

  no shutdown



Note: Portions of the above configuration are defaults which will only display if verbose output is requested. These items have been printed to indicate additional advanced options should they be required.

Note: The examples presented above apply to the Adtran Operating System, however, the concepts will apply to all vendors. If you are not using AOS devices, please contact the vendor of the equipment for technical support.

WARNING! Special care must be taken with the NAC Location in vWLAN. Currently this location is tagged as VLAN 1 and this tag cannot be changed. This prohibits VLAN 1 from being tagged at the BSAP’s Ethernet interface.

The next step is to configure DHCP server pools. These pools serve two purposes: they facilitate IP addressing for wireless clients and allow location discovery to complete. Please see the Useful Links sections for more information on configuring DHCP in AOS. For all other DHCP servers, please contact the vendor of the server.

Locations in vWLAN are found under Configuration>Role Based Access Control>Locations. The locations which will be created in vWLAN should be directly related to the networks previously created. To create a location, click Create Location, or click the location name if you need to edit an existing location.


Input an appropriate Name for the location, assign the VLAN ID, and input the CIDR. CIDR, as used in vWLAN, is short for CIDR notation which is specific syntax for specifying network addresses and subnet masks. CIDR notation appends the slash notation of a bit mask to the network address. For example, would translate to Click Create or Update location once the information is correct.


Once locations are configured and the BSAPs have discovered these locations, the Status > Locations screen should indicate what locations are ACTIVE and which of the BSAPs discovered the locations. If a location is not ACTIVE or a BSAP does not appear in the Access Points list, then check the switch configurations to make sure ports have been properly configured to support 802.1Q. Also verify that a DHCP scope has been created for the subnet.


Location Groups are optional, and they are configured under Configuration > Role Based Access Control > Location Groups. Location groups are applicable when a role might not be isolated to a specific network, for example, a business where the main office and branch offices use different networks for the same logical group but all employees should have the same role. Editing or creating a location group is made simple by clicking the plus [+] or minus [-] signs to add or remove existing locations to or from a group. Make sure to give the location group a good Name, then click Create or Update.


Services and Service Groups

Services are located under Configuration > Role Based Access Control > Services. Services are protocols and associated ports used for various applications. vWLAN is pre-configured with services for many common protocols and ports. If a new service is required, click Create Service on the services page, or click the name of an existing service to edit it.

Input an appropriate Name for the service. The Protocol drop-down menu will list the supported protocols available. If the protocol selected requires a port number, then fill out the Port field. Add any Notes which might help describe the service, and click Create or Update service.


Service Groups combine individual services into a single entity thus simplifying the role configuration later. For example, Adtran suggests a service group for common protocols such as DNS, HTTP, and HTTPS. You can create or edit service groups under Configuration > Role Based Access Control > Service Groups. Choose an appropriate Name, and click the plus [+] or minus [-] signs to add or remove services to or from the group. Save the changes by clicking Create or Update.


Destinations and Destination Groups

vWLAN uses roles to define firewall rules which are enforced at the AP. Because an AP is an edge device, the firewall does not need to be concerned with the source fields of a traffic flow. Rather, only the destination and direction of a packet is important. There are three (3) types of destinations (host, hostname, and network), all of which can be configured under Configuration > Role Based Access Control > Destinations. Click the name of existing destination to edit, or choose one of the Create links for the appropriate type.


A Destination Host is a single IP address, or host, but not a hostname. A destination host is the most basic type. You can configure a Name and Address for destination hosts. The address should be a single IP address. You can choose to Invert the destination host which means the destination will be every address expect the assigned address. This is useful if users should have access to any destination except this one.


A Destination Hostname helps provide a walled garden type experience using the Un-registered role. Destination hostnames can only be used in the Un-registered role; they cannot be applied to other roles. A destination hostname contains two fields: Name and Address. The Name is a simple descriptor, and the Address is more accurately described as a hostname or URL, not an actual IP address. Un-registered users can be granted access to these destinations. Destination hostnames are required for proper support of third party certificates in Captive Portal authentication, but they can also be useful if users that are forced through Captive Portal authentication need to access any particular web site without first authenticating. More information on Captive Portal authentication and the Un-registered role can be found in the Useful Links.


A Destination Network requires a Name, network Address, and Netmask. The Address must be a valid network address, not a host address, for the Netmask being used. For example, is a valid entry when using, but is not. Even though is a valid host address, it is not the network address given the Netmask of


Note: Inverting destinations can cause unexpected results if not done carefully. An inverted destination at the top of the list may prevent a traffic flow from being processed by later entries. The BSAP will enforce role policies in a top-down fashion, and an action is applied based on the first match in the list. Subsequent matches are not processed.

Destination Groups are used to simplify role creation by allowing multiple destinations to be contained in a single entity. Destination groups are listed under Configuration > Role Based Access Control > Destination Groups. Like other groups, simply click the plus [+] or minus [-] signs to add or remove destinations to or from the group.


Note: A destination group may contain any combination of destination hosts, hostnames, and networks, however, it is important to remember that destination hostnames should only be used in the Un-registered role. In general, a destination hostname cannot be selected when editing roles other than the Un-registered role, so it is important to exclude destination hostnames from a group that will be used roles other than the Un-registered role.


Roles bring all the locations, services, and destinations together into a meaningful policy which is applied to clients to enforce class of service, bandwidth shaping, post login redirection, and firewall rules. The roles are enforced by the AP at the edge of the network such that client traffic can be placed securely on the LAN without needing to tunnel through vWLAN. Roles are editable or configurable by clicking an existing role or Create Role on the Configuration > Role Based Access Control > Roles page.


Start off by choosing an appropriate Name and Location for the role. The location (network) can be a single element or group. Machine Authentication Enforcement relates to a type of two factor authentication associated with computer and user authentication in 802.1X. More information on this feature can be found in the vWLAN External RADIUS-802.1X Authentication guide in the Useful Links. Allow Client to Client applies to client traffic on the same AP, not necessarily client traffic on the same network. If client to client traffic is allowed within the network, then this box should be checked.


Next, the Firewall Rules need to be defined. New firewall rules can be added by clicking Append Firewall Rule, and each row can be moved up or down by clicking and dragging the arrows to the left of each row. Each column is presented as a drop-down menu where defined values or previously configured items can be selected. There is an implicit deny rule at the bottom of the firewall rules, so it is not required to explicitly define a rule for this.


The firewall rules are processed in a top-down fashion, so it is important keep track of what is being allowed or denied above any additional rules that are configured. For example, sometimes the desire is to deny traffic to a single network, but allow all traffic to any other destination. This can be done by configuring a deny rule first, followed by an allow any rule.



Authentication is a far reaching subject that is mostly outside of what is required for an initial deployment. We give a brief mention of some key authentication items here, but more in-depth information can be found in the Useful Links.

Note: You will need to configure 802.1X authentication servers prior to configuring SSIDs. If 802.1X is a requirement for your deployment, please read vWLAN External RADIUS-802.1X Authentication

Internal Authentication is maintained by vWLAN without the need for an external server. There are three internal authentication mechanisms available.

  1. Usernames and Passwords
  2. Guest Account Information
  3. MAC Devices

Internal Users are local users which can be used with Captive Portal authentication. Guest Users are similar to regular users in that the information is used with Captive Portal Authentication, however, these guest users are unique in that they expire by default (the value is configurable), and they are associated to Hotspot Plans. Hotspots allow users to create their own accounts without manual intervention of an administrator. More information on Guest users and Hotspot accounts can be found in the Useful Links.

MAC Devices are another useful internal authentication type. These devices can bypass other types of authentication, and be placed directly in a role. Effectively, MAC device authentication whitelists a device, however, it can also be used to blacklist devices by placing a user in a role with limited to no access. MAC devices require a Name, Address (layer 2 MAC address), and Role.

External Authentication allows vWLAN to integrate with existing authentication servers (AS) and directory services. External server types include LDAP, RADIUS, and SIP2.

LDAP servers allow vWLAN’s Captive Portal authentication to integrate with an existing directory service. This can facilitate a single sign-on experience such that end-users do not have to remember as many usernames and passwords. It also helps maintain existing password policies as the network administrator can enforce these policies from a single server.

RADIUS can be used with Captive Portal authentication, but more commonly it used to enforce 802.1X authentication on an SSID. In either case, the principles are the same. The difference is that RADIUS web authentication uses vWLAN to communicate with the AS and RADIUS 802.1X uses the APs to communicate with the AS. Further, when 802.1X is enforced on the SSID, EAP will be encapsulated within RADIUS. This brings a client element into the authentication mechanism. This client mechanism helps facilitate Machine Authentication which utilizes 802.1X to enforce both computer and user authentication. This allows users to keep the same login credentials on their own devices, but still place those devices in a different role. In other words, it helps segregate personal devices from official devices.

Captive Portal authentication requires a wireless client to open a web browser and authenticate through a web portal. Many hotels use this type of authentication to force clients to a splash page or landing page before being granted access to external resources. Although hotels are a good example, this practice extends well beyond the sphere of hospitality.

Note: In order for Captive Portal to function properly, the role on the SSID must be set to Un-registered (discussed further in SSIDs ). If the role on the SSID is not Un-registered, then users will not be redirected.

Note: A common practice is to simply have wireless clients click a button on the splash page instead of inputting login credentials. You can find a vWLAN Single Click Customized Login Page guide in the Useful Links section below.

Service Set Identifiers (SSIDs)

SSIDs are the portal to the wireless network, so it is important to understand each aspect of this parameter. SSIDs are located under Configuration > Wireless > SSIDs. Here you can click an SSID’s name to edit the SSID, or you can click Create SSID to create a new SSID.

The Name/ESSID is the most noticeable and familiar aspect of a wireless network. This is the name that will display in a client’s wireless network list. The Broadcast SSID option does not enable/disable the SSID, but rather it hides the SSID. You can choose to Convert Multicast/Broadcast Network Traffic to Unicast. You can find more information on this setting in the Useful Links.


Note: Even though an SSID can be configured such that it does not broadcast, the SSID can still be found through various means.  Hiding an SSID does not provide any protection from intruders, but rather makes the network invisible to casual users.

The next two options are possibly the most important as they determine how easy it will be to access the wireless network and whether or not wireless traffic is encrypted. Authentication controls access to the network. The Cipher determines how client traffic will be encrypted.


Note: The Wi-Fi Alliance, which provides certifications for interoperability of Wi-Fi products, maintains strict guidelines for Wi-Fi Protected Access authentication. Adtran strives to follow these guidelines, and therefore WPA or WPA+PSK is not allowed by itself. Also, WPA2 with TKIP only is not allowed. WPA version 1 is still supported so long as it operates in a mixed mode with WPA2.Older versions of vWLAN may still allow the combinations excluded by the Wi-Fi Alliance.

After the Authentication and Cipher (if applicable) have been selected, there may be extra fields displayed requiring the key information. Likewise, if WPA, WPA2, or WPA+WPA2 is selected, then a Radius1x auth server must be selected (an external RADIUS 1X server must already be configured).

Depending on the Authentication it may be possible to select a Login Form and a Role. The Login Form can be specified on the SSID, or you can choose to use the default from the AP template (discussed later). The SSID Login Form will take precedence. The Role determines whether users will be forced through Captive Portal authentication or placed directly into a role without further authentication.


Note: MAC device authentication takes precedence over SSID defined roles. The authentication order of precedence is listed here.

Note: Creating or editing an SSID may not generate a domain task unless the SSID is already applied to an AP template that is selected for at least one active AP. Any new SSIDs must be added to an AP template. You will need to run the domain task to apply changes to the AP.

AP Templates

The AP template is the actual BSAP configuration. AP templates can be edited or configured under Configuration > Wireless > AP Templates. You will start by supplying a Name and SSH Password. (Note: The default SSH password is blue1socket, and this field can be left unmodified). The Login Form here will act as a default for all SSIDs unless the SSID has been explicitly configured with a unique form. The DNS Server(s) For NAC Users refers to Un-registered users who must use Captive Portal authentication.


Be sure to select the AP firmware Release and Server in the AP template. The BSAPs cannot receive their configuration if the firmware is not selected in the template, and they will reboot continuously until the firmware image is selected. If no AP firmware is uploaded to vWLAN, then the drop-down menu will be blank. AP firmware can be uploaded under Configuration > Wireless > AP Firmware, and firmware can be applied to all templates when it is uploaded.


After selecting the firmware, confirm the Per Radio Setting fields. The Radio Mode should be set to “AP Mode” to allow client connections. The Dynamic RF Mode should be set to “Set Once and Hold” for normal use cases. You can also adjust the Wireless Mode, but be sure not to exclude legacy clients from connecting if these devices exist in your network.


Finally, add the SSIDs in the AP template by clicking the plus [+] sign in the right pane of the SSID field. Each radio has its own set of SSIDs, so be sure to add the SSIDs to both radios as needed. You can also remove SSIDs by clicking the minus [-] sign.


Note: Adtran recommends no more than 8 SSIDs per radio to ensure that each service set can properly service all clients. Each SSID adds its own management frames to the already shared medium, increasing the amount of time an AP must expend synchronizing the network as opposed to servicing clients.

Scroll to the bottom of the AP template, and click Update AP Template to save the changes. This should generate a domain task to apply changes to APs if the template is applied to active BSAPs. If the template is not applied to APs, then apply the template to APs under Configuration > Wireless > Access Points. You can select multiple APs by simply clicking each row. A pending domain task will be indicated in the top right corner of vWLAN. Click “Domain Tasks” or browse to Administration > Admin Tasks, and execute the job “Must apply configuration to APs” by clicking the play button.


Additional Configuration Considerations


There are two ways to create new domains in vWLAN.

  1. Manually under Configuration > System > Domains
  2. Automatically by restoring a domain backup file

Automatic creation happens any time a domain backup file is being restored. This allows an existing domain or backup file to act as a template domain thus decreasing the time required to create new domains. Generating the domain template starts by backing up an existing domain. This is done under Administration > Backup/Restore. Click the Back Up One Domain radio button; the Domain drop-down menu will appear. Select the domain to use as the template, and then click Run.


Save the backup file and store it in a good location. Now, take the backup file and restore from the same page as before.  When you click the Restore Domain radio button, a Browse button should appear. Browse to the file that was recently created. Next, choose a name for the new domain. Be sure to read the help text before clicking Run.


Regardless of the method chosen above, once the new domain is created administrators can be given additional permissions for the new domain. If this new domain is going to be used as a template, then it may be a good idea to cleanup portions of the configuration that should not be replicated in each new domain. Move into the new domain by selecting it from the Domain menu in the center-top of vWLAN. Clean up items in the following order.

  1. AP Templates
  2. SSIDs
  3. Roles
  4. Locations and Location Groups
  5. Destinations and Destination Groups

Once the domain has been cleaned up, follow the above steps again to create a real domain template. Use this file to create new domains without the need to recreate every setting. Each new domain will need to have AP firmware added as well. You can use existing firmware files by editing the AP firmware on the Platform tab under Configuration>Wireless>AP firmware. The administrator will need platform-level read-write options.

When the domain is ready for use, move APs into the new domain. You can change an AP’s domain under Configuration>Wireless>AP Licenses. Select multiple APs by clicking each line, or use the search to filter the AP list, and then click Select All. After the APs are selected, choose the new domain from the drop-down menu near the bottom of the screen. Note: AP hostnames will be lost when APs are moved to a new domain. Make a note of all existing AP hostnames prior to moving any APs to a new domain.

Note: AP hostnames will be lost when APs are moved to a new domain. Make a note of all existing AP hostnames prior to moving any APs to a new domain.

Configuring a Basic Role to Allow All Traffic

It is useful to have a role that will essentially have no firewall. Any role without firewall rules will have an implicit deny action applied. This means that, by default, a new role will block all traffic. Creating a role that allows all traffic is efficient for testing basic wireless access. There are two ways to configure this role. Either allow all traffic both ways, or allow traffic outbound. When allowing all traffic outbound, the role still needs to allow DHCP-Server incoming in order to facilitate DHCP. Adtran recommends this approach as it will also facilitate testing DHCP configurations by changing the role’s location.


Useful Links

Labels (1)
Version history
Revision #:
1 of 1
Last update:
‎06-13-2014 10:44 AM
Updated by: