Archive for April, 2011

New SSID Broadcast Controls with AP Tagging

When deploying a new wireless network, sometimes network administrators will run into situations when they don’t want to broadcast a certain SSID in specific areas of their campus. Or vice versa, sometimes it is desirable to only broadcast a particular SSID in a restricted area. A great example would be when they want to provide open, unrestricted guest access in a corporate lobby for visitors but they don’t want to broadcast this SSID in other areas because they don’t want to employees accessing social networking sites during business hours. Or perhaps an administrator doesn’t want to broadcast an SSID on the APs around the perimeter of a facility to provide geo-fencing.

We have now added an easy way to accomplish this through Dashboard using AP tags. AP tags are a way of grouping APs together by applying an identifying tag, such as “Building_4”, to create an easily-searchable group of all the APs located in a certain building. So how do you apply a tag to an AP?  There are two simple ways, either for an individual AP or for a large group of APs.  To just tag a single AP, go to the AP details page:


Go to the Edit Configuration link, and add Tag names, such as “Lobby”:

Then go to the SSID Availability page and select “This SSID is enabled on some APs…” from the AP selection control.  Enter the name of the tag of the APs that you want to broadcast the SSID from, and you’re done! This specific SSID will only be broadcast from the APs belonging to this tagged group.

In some situations, there may be a large number of APs that you want to tag into a certain group, perhaps all the APs in a single building on a college campus. In this case, you can tag en masse from the Access Points page under the Monitor tab. Simply check the APs you want to tag, select “Add tags” from the Actions drop-down menu and enter the name of the tag to use:

AP grouping with tags gives you a simple way to segment SSID broadcasts within a single network by building, floor or room, providing you with a new level of control over your network. AP broadcast by tagging is available now for all Enterprise customers. Try it out and let us know what you think!

See How Simple Your Network Can Be

Customers tell us all the time that they love using the Meraki dashboard. We like to think it’s never been easier to manage a network. See for yourself with these videos. Don’t forget your popcorn!
(more…)

Using Spectrum Wisely with Band Steering

Do you ever wonder what happens on your wireless network when a mix of older and newer clients associate to an access point? Are the newer, faster clients hampered by older, slower clients? These are frequently asked questions when considering upgrading to 802.11n or adding 5 GHz capability to a network that started with 2.4 GHz only. The answer is found in band steering. Band steering is a radio management technique Meraki APs use to improve capacity, throughput, and the experience for users of crowded wireless networks.

Back when 802.11b was king

In the early days of wireless LAN, 802.11b was king, and its kingdom was the 2.4 GHz band. At a maximum rate of 11 Mbps, it reigned for a few years until 802.11g zoomed past at 54 Mbps. 802.11g became incredibly popular, and most of today’s mobile WiFi devices have at least an 802.11g radio inside. 802.11g is designed to co-exist with 802.11b, and their data rates are close enough that most people weren’t terribly concerned about the network performance when 802.11b and 802.11g clients both associated to a network.

802.11n takes the crown

Things are different now with 802.11n. Its data rates go to 150 Mbps for a single-stream, and these days, triple-stream MIMO cranks the speed up to 450 Mbps (per radio), such as in the Meraki MR24. Figure 1 shows the comparison of data rates between wireless LAN versions.

Figure 1: Wireless LAN maximum data rates

Additionally, 802.11n can use the 5 GHz band, which is nearly always less crowded and with less interference than the 2.4 GHz band. But it also works in 2.4 GHz, and 802.11n clients can happily associate there, in the mix with 802.11b and 802.11g clients. Table 1 shows the frequencies available to different types of wireless clients.

Table 1: WiFi frequency bands

So what happens to the 802.11n clients when they are in 2.4 GHz alongside 802.11b and 802.11g clients? Are they limited to 54 Mbps or 11 Mbps? Can they operate at 150 Mbps and higher?

Waiting for slower clients

The answer depends on how the wireless network is configured. Older clients can’t understand transmissions sent at the faster rates that newer clients support, so the network can be configured to support both. For example, if an access point sends a transmission to an 802.11n client, the first part of the transmission, the header, should alert all clients that the contents are intended for an 802.11n client and the contents will be sent at a fast rate. 802.11b and 802.11g clients can then safely ignore the rest of the transmission. However, for this to work properly, the header needs to be sent at a rate understood by the slower clients. This means that 802.11n clients essentially have to wait a bit longer than they would if the header didn’t have to be sent at a slower rate.

Another penalty paid by 802.11n clients mixed in with 802.11b/g is that the mechanism used to determine channel availability and alert other clients of an upcoming transmission must follow the method supported by the older clients. This is a function of the medium access control (MAC) layer. 802.11n clients must send a short message that informs the older clients of the 802.11n transmission that will follow. This message, called the CTS-to-self message (clear to send to self), must be sent at the slower rates that the older clients can understand, or otherwise it’s of no use.

Band steering helps to use spectrum efficiently

So what can be done to get the maximum throughput out of 802.11n devices? One drastic technique would be to disable all 802.11b and 802.11g clients, but given the number of these devices still in users’ hands, it’s not a very practical solution. Instead, there is a more graceful approach: band steering.

Band steering sends 802.11n clients to the 5 GHz band, where 802.11b/g clients cannot go, and leaves the 802.11b/g clients in 2.4 GHz to operate at their slower rates. The 5 GHz 802.11n clients then operate at their full rate and the 802.11b/g clients aren’t affected down in 2.4 GHz.

Band steering works in the access point by directing 5 GHz-capable clients to that band. When the access point hears a request from a client to associate on both the 2.4 GHz and 5 GHz bands, it knows the client is capable of operation in 5 GHz. It steers the client by responding only to the 5 GHz association request and not the 2.4 GHz request. The client then associates in the 5 GHz band. See figure 2, below.

Figure 2: Sending a client to the 2.4 GHz or 5 GHz band

Of course, this only works if the access point has two radios inside: one for the 2.4 GHz band, and one for the 5 GHz band. The radios must be able to work concurrently, too. If you’re deploying wireless for a dense, bandwidth-intensive environment, it’s important to deploy access points with dual concurrent radios, or else band steering won’t be available.

Open spectrum

Perhaps the most appealing aspect of operating in the 5 GHz band is the additional available spectrum compared to the 2.4 GHz band. 5 GHz channel availability may depend on the country of operation, but in the US it is common to have eight non-overlapping channels in 5 GHz, compared to three non-overlapping channels in 2.4 GHz.

The 5 GHz band generally has less interference than the 2.4 GHz band. This isn’t only because of WiFi clients – microwaves, Bluetooth devices, and many consumer products such as cordless phones all operate in the same 2.4 GHz band. This doesn’t mean the 5 GHz band is completely interference-free; however, in most environments it is not as crowded as the 2.4 GHz band.

The access point can steer the client to 5 GHz, but it doesn’t lock it out of 2.4 GHz if the client really wants to associate there. Sometimes, the signal conditions or signal strength might be better in 2.4 GHz than in 5 GHz, so it doesn’t make sense for the client to shift up to 5 GHz. In this case, the conditions may not allow the client to operate at full rate anyway, so there is little penalty if it associates in 2.4 GHz.

Other tips

Band steering is generally quite helpful in assigning clients to their appropriate bands. Access points can use band steering when they have two (or more) radios and support both 2.4 GHz and 5 GHz bands simultaneously.

A more drastic measure is to disable 2.4 GHz operation entirely. This takes advantage of the additional capacity and reduced interference in 5GHz compared to 2.4 GHz, but legacy clients are not capable of using it.

Another technique to consider is to disable the slowest (legacy) 802.11b rates altogether. These are 1, 2, and 5.5 Mbps. The highest 802.11b rate, 11 Mbps, is still available for those clients, but they will not be able to use the slower rates.

Naturally, choosing band steering settings in Meraki wireless networks is as simple as selecting an option in the dashboard. Figure 3 shows this part of the dashboard.

Figure 3: band steering selection in dashboard

The great news is that if you support only 2.4 GHz now, upgrading your wireless network to 802.11n and 5 GHz will open up significant capacity and will lead to a better experience for all the network users. If you already support 5 GHz in your network, you can use these tips to maximize your wireless network capacity and make the most of 802.11n and your spectrum.

Peeling the VPN Onion

A virtual private network, or VPN, is a connection established between two peers such that each can behave as if they are on the same subnet. VPN is very commonly used to connect remote workers to a corporate network so they can access email, files, and network resources when away from headquarters where these resources typically reside.

Teleworker VPN

Figure 1: Teleworker VPN extends the corporate network to the branch or home office

Road warriors rely heavily on VPN and depend on its security and reliability. Luckily for them, they don’t have to deal with the complexity of configuring and managing VPN. Unfortunately, VPN deployment is no easy task for any IT administrator. Until now, that is. Meraki’s new Teleworker VPN makes configuration and deployment painless, and it even eliminates some previously required hardware components entirely.

1-2-3

This is how easy it is to get VPN up and running:
1) Download the VPN virtual concentrator from the dashboard and install it in a VMware virtual machine

Figure 2: download VM image for VPN concentrator

2) Click “Enable VPN” on the Network-wide settings page

Figure 3: tunnel AP traffic back to VPN concentrator with one click

3) That’s it! Any access point on this network will now have a VPN connection back to the corporate network, and it will be completely transparent to the user.

There is no client-side software to install, no VPN concentrator box to manage at headquarters, no messy provisioning on each client machine. The remote worker connects to the Meraki access point and sees all the network resources that are available when physically located at headquarters.

Meraki’s cloud-based architecture makes this all possible. Access points automatically traverse NAT and firewall settings using a technique called hole punching. This allows the APs to find and connect to the cloud controller for configuration and establish the secure link to the corporate network for VPN traffic. There is no AP provisioning needed from the IT administrator, and the APs receive and install the correct configuration for their network automatically.

Some background: IPsec

Let’s take a look at just a bit of what happens behind the scenes when using a VPN link via IPsec.

IPsec is a group of protocols that provides mutual authentication and encryption between trusted peers so that an end-to-end connection can be secured. It operates at the IP layer, meaning any application that uses IP can be protected by IPsec, and applications do not have to be redesigned or adapted to be secured.

VPN has many, many options and controls. Some of them handle authentication and identity functions, while others handle encryption and securing of data. Instead of exhaustively going over each, it’s best to first gain an understanding of a commonly implemented form of VPN. A simple way to understand what happens in VPN via IPsec is to look at the packets in encapsulating security payload (ESP), a common type of encryption and authentication. Tunnel mode of ESP is used when connecting a remote user to a network or when connecting two routers that link sites.

Peeling the onion: packets within packets

Consider first a normal, unsecured IP packet. The major structural parts of the packet are the header and the payload. The header has many components, but for this discussion, the most interesting one is the protocol field. This field describes the protocol of the information contained in the payload. Very often the payload contains a TCP datagram, so the IP header will indicate protocol 6, for TCP.

The IP payload then contains the TCP datagram: a TCP header and TCP payload. This is the same TCP/IP packet type that is so widely used over the Internet today.

Figure 4: original, unprotected packet

This method provides no security for the communicating parties. An eavesdropper could view packets on the wire and listen to the conversation between a source and destination. Clearly, this is not suitable for private communications where sensitive data needs to be exchanged. That’s where VPN comes in.

In a configuration providing a VPN over IPsec using ESP, IPsec takes an IP packet, secures it completely (including IP header and payload), and wraps it in a new payload format, called encapsulated security payload. It attaches a new IP header and modifies it to point to a payload (ESP), instead of the original unprotected IP protocol payload. The original IP packet, including header and payload, become the new payload data contents of the encapsulated security payload. ESP also includes a trailer, after the payload, that includes some padding and points to the payload type (in this case, TCP). Authentication is optional with ESP, but highly recommended. When using authentication, a few more bits of information are added to the ESP trailer.

Figure 5: IPsec encrypts and protects the original packet

That summarizes the packet structure when using IPsec with ESP. But one might wonder how, exactly, is the information actually protected? The data of interest, now part of the encapsulated security payload, is still inside the packet. How is it protected from prying eyes? To find out, we need to peel another layer of the VPN onion.

Security associations

Using encryption and authentication requires that each peer verify the identity of the other and have some way to de-encrypt the desired data. This means they must have knowledge of secret keys, algorithms used, and protocols used (for example, AH or ESP). Security associations are simply parameters that describe the algorithms, secrets, and keys used in a one-way connection. Naturally, most connections are two-way, so a pair of security associations is required in the case of IPsec with ESP. These parameters are stored in the security associations database (SADB). The SADB keeps track of a large number of parameters, including the ESP encryption secret key, the ESP encryption algorithm, and the ESP authentication enabled flag.

If data is protected using encryption and authentication, and if encryption/decryption is performed using secrets, it follows that knowledge of the secrets is a very critical requirement for ESP to function properly. The transfer of knowledge of the secrets must be done in a secure way so that unwanted parties do not learn it. There are several ways to do this, ranging from manual installation to key management protocols. Key management protocols allow for the secure exchange of keys (and other security association parameters) without the need for manual installation, making them suitable for large-scale deployment and configuration.

Choose your encryption algorithm

ESP itself does not specify the algorithm to use for encryption, but instead lists several from which to choose. A very commonly used algorithm is AES-CBC: advanced encryption standard with cipher block chaining (mode). AES was selected by the USA’s National Institute of Standards and Technology (NIST) as the government’s dedicated encryption cipher, with the expectation that it protects unclassified, sensitive information at least until the next century. AES is commonly used with 128-bit or 256-bit key sizes, making attacks extremely processing intensive and thus completely impractical. Another common algorithm is TripleDES, or 3DES, which is based on the data encryption standard (DES). DES was found to have weak keys, but TripleDES gets around this by processing each data bit block three times in a chained fashion.

Identity

Even if information is encrypted, it’s still necessary for each peer to establish and verify the identity of the other party. When using ESP with authentication, as is recommended, a commonly used authentication algorithm is HMAC-SHA1-96: hashed message authentication code with secure hash algorithm 1, using a 96 bit-long authenticator, and operating on 64-byte sized blocks of data. It ensures the packet authenticity and that it cannot be altered while in transit.

Peeling even more layers

There are many more details that are involved in making a VPN connection work properly and securely, but they are out of scope for this article. The key exchange methods and protocols, for example, can provide protection from attacks and can even protect future keys from being stolen by unauthorized parties holding a current key. Another topic ripe for illustration is how peers initiate communication in the first place – the discovery process.

This article discusses one type of VPN, remote access. Site-to-site VPN is another type of connection and is used to connect two fixed locations between gateway points, replacing leased-line WAN connections. Meraki’s MX router has integrated site-to-site VPN capability and is as easy to turn on as the Teleworker VPN shown here. More information is on our website at http://meraki.com/products_services/vpn/.