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.
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 .
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.
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 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 192.168.10.0 255.255.255.0 might exist with a VLAN tag of 10. This would translate to vWLAN as a Location.
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.
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.
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.
Adtran suggests configuring location-related items in the following order before bringing the BSAPs online or applying changes to the AP.
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
interface eth 0/2.1
vlan-id 1 native
ip address 10.19.213.254 255.255.255.0
ip access-policy Management
interface eth 0/2.10
ip address 10.10.10.254 255.255.255.0
ip access-policy Faculty
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 10.19.213.254 255.255.255.0
interface vlan 10
ip address 10.10.10.254 255.255.255.0
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.
interface gigabit-switchport 0/1
switchport mode trunk
switchport trunk native vlan 1
switchport trunk allowed vlan all
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, 10.10.10.0 255.255.255.0 would translate to 10.10.10.0/24. 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 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.
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, 10.10.10.0 is a valid entry when using 255.255.255.0, but 10.10.10.128 is not. Even though 10.10.10.128 is a valid host address, it is not the network address given the Netmask of 255.255.255.0.
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.
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.
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.
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.
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.
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.
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.
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.
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.
There are two ways to create new domains in vWLAN.
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.
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.
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.