HOWTO: Beat the Capture Portal to Get Your Gadgets Online

The average person has something like 1.5-2 wireless devices according to most studies.  I'm going to extrapolate that the average geek has more on the order of 3.5-4.  When we travel, our gadgets become our lifeline to our normal home life.

On a recent business trip, I left town with my iPhone 5, Nexus 7, laptop, and Chromecast (I only take the Roku on longer trips.).  This trip though was my first with the TP-Link WR-710N travel router.  I bought this on a whim when it came up for cheap on Lifehacker's daily deals.  My initial thought was that I could set it up identically to my home SSID and plug in the hotel's wired port.

At this particular hotel though, there were no wired ports so I had to use another feature of this router.  It has a WiSP (Wireless Service Provider) option for it to use for WAN/Internet.  After configuring the WiSP interface to connect to the strongest AP for the hotel's SSID, I hooked up my laptop to my home SSID and answered the captive portal once.  From there all of the rest of my devices jumped on with no problem.

Another feature of using my own router is that I was guaranteed that communication between my iPhone and the Chromecast would be supported.  Unfortunately there was one downside to the WiSP interface.  It insisted on being configured to connect to only one BSSID which meant if the AP went down it wouldn't roam automatically to a better signal.  I've looked into using DD-WRT instead of the built in firmware to get around this, but so far it seems that this particular model is not DD-WRT supported.  All in all, my solution worked and I look forward to giving it some more road tests.

Hello? ¿Hola? No, Bonjour!

Last fall I helped a local school district install a Cisco wireless network consisting of 1142n APs and a 5508 controller.  All was working well until recently when one of their techs received the district's first AppleTV.

Of course my first question was what VLAN(s) the AppleTV and the iOS device were connected.  That was the first problem which was easily fixed by placing them on the same VLAN.  The next problem is how Apple's devices find other devices on the same layer 2 network.  Apple uses Multicast DNS (mDNS), which they call Bonjour, to locate devices.  Every device on a subnet advertises its capabilities to the multicast address 224.0.0.251.  By default these advertisements are set to have a Time To Live (TTL) of 1 which prevents them from crossing routed boundaries even if multicast routing is configured on the network.

It was easy enough to put the AppleTV onto the same wireless VLAN as the user devices so we didn't have to come up with a solution for that.  To get the two devices talking is actually quite simple.  By default Cisco WLCs have multicast disabled.  This of course prevents Bonjour's discovery process from functioning.  Enabling multicast is done under the Controller tab of the WLC web page.  There are three options, disabled, unicast and multicast.

You might wonder how you can have unicast multicast, but it's not a contradiction in terms.  Because of the way traffic is tunneled from the APs to the controller, the multicast traffic is actually sent to the APs using CAPWAP unicast packets.  If you switch to multicast multicast mode and the switches are properly configured, the CAPWAP packets containing the wireless multicast traffic is only sent to APs that have joined the multicast CAPWAP group.  In a larger environment this can cut down on the amount of traffic sent as well as eliminate traffic going to APs that don't need the packets.

Most of the major networking vendors have released or are planning to release solutions to the problems Bonjour faces in the enterprise network.  In addition there have been petitions online to Apple  for them to make their products work better in enterprise networks.  Hopefully soon these challenges will be a thing of the past and Apple products will "just work" at home and in the office.

Hey Window! You Make a Better Door Than You Do a Window.

Over the past two months, I have been battling with a Cisco Aironet 1310 wireless bridge between our main building and a physician's office that we rent across the street.  This physician's office is one building out of a cluster of 15 in a "Doctor's Park".

A few years ago when we put in this link, we were the only wireless in the area.  Within the last 6 months several of the physician's offices and a neighboring nursing home have added wireless infrastructure.

When our problems started, I noticed that our signal strength had gone from an average of -69dBm to -82dBm and our signal to noise ratio was around 10 dBm.  My first thought was obstruction having recently had a different link knocked out by a new HVAC project on the roof of one of buildings interfering too much with the Fresnel zone of another link.  I went up to where the radio was on the main building and took a look.  Nothing new was in the line of site.

Having ruled out the obvious, I fired up the Cisco Spectrum Expert on my laptop and sat up near the radio.  Almost immediately I saw something that wasn't quite right.  All of my APs and bridges are set to use channels 1, 6, or 11.  On the laptop though I was seeing active APs on channels 3 and 8.  Of course since the 2.4Ghz channels overlap, this was causing cross channel interference on all three of the channels that my bridge was configured to be able to use.  As I looked more closely at the Cisco Spectrum Expert information I found the SSIDs associated with these interfering APs.  This is where I got a break, I recognized one of the SSIDs as being from another healthcare entity from another town.  I went back to looking outside and thinking where this might be coming from.  Eureka, one of the physician's offices had a new sign out front with the other entity's logo.  Thankfully the network engineers on their side were gracious enough to reconfigure their stand alone APs to use channels 1 and 11 leaving me 6 for my bridge.

You're probably asking, what does this have to do with a window being a door?  Well yesterday after having resolved our bridge issues for almost a month by my detective work, the problem came back.  This time though, I couldn't find any interference.   Instead, the screen showed something on channel 6 with a very high duty cycle.  I confirmed it was my bridge that was on channel 6.  This puzzled me so I drove over to the far end of the bridge to see if something was amiss there.  I walked up to the radio with my laptop and saw the same type of high duty cycle, but again no interference.

As I did a visual sweep of the room I saw that the window in front of the AP (I know this isn't ideal, but we rent the building.) was partially open such that the metal frame of the window was just about centered in front of the radio.  I asked the clinician whose office it was how long the window had been open.  They told me it had been open for about 2 hours... exactly the amount of time that the bridge had been having problems.  I promptly closed the window and presto the signal strength went back to normal and the duty cycle returned to normal as well.  Once again, the network was undone by the Human Network.

Using Cisco Wireless Lan Controllers for a Wired Guest Network

Most people are familiar with using Cisco's mobility anchors to provide a wireless guest network.  The usual topology is that you have a controller with CAPWAP access points connected to it and then a foreign "anchor" controller that is located in the DMZ.  Between the two controllers traffic is tunneled to logically separate the traffic from the rest of the regular network. In this way guest traffic can be effectively managed while keeping internal resources secure.

The same separation can be achieved for a wired guest LAN by using the same WLC architecture.  Setting it up requires the following:

• The WLC inside the network must have it's interface setup as a dot1q trunk to handle multiple VLANs
• UDP Port 16666 or IP Protocol 97 must be able to pass through the firewall between the inside WLC and the anchor WLC.
• A dedicated L2 VLAN for the guest wired network
• Mobility Groups are already configured on the WLCs.
• DHCP configured on the Anchor Controller

Configure the Ports

First go to the switch connected to the local WLC and do the following assuming that the WLC is connected to Gi1/0/1 and the new guest wired vlan is 601

switch#configure t
switch(config)#interface Gi1/0/1
switch(config-if)# switchport trunk allowed vlan add 601

Next go to the switch connected to the access port(s) that you want on the guest wireless and do the following:

switch#configure t
switch(config)#interface range gi2/0/1 - 5
switch(config-if-range)# switchport access vlan 601

 Configure the Local WLC


Login to the local WLC web GUI and go to Controller and then Interfaces and click New.  This will bring you to the following screen where you give the Interface a name and tell it what VLAN it should be on.  

Once the information is entered, click apply.  This will bring you to another settings page for the new interface.  In this screen you need to click the box marked Guest LAN and then click Apply.

Now go to WLAN and then click Go next to where it says Create New.  This will bring you to the following screen where you will choose type Guest LAN and give the profile a name.

Clicking Apply will bring you to the WLANs Edit screen for the new profile.  Here there are a few choices to be made about security.  The default is that users will need to login using web authentication if they want onto this guest network.  This requires that you have either setup local usernames and passwords, perhaps through the lobby ambassador setup, or have guest accounts through AAA.  For this example I will use the Web Passthrough option with makes the user accept an acceptable use policy before gaining access.  On the general tab I clicked enable and chose the guest-wired-lan interface that we created earlier as the Ingress Interface.

Next I clicked on the Security Tab and Layer 3 Tab to change the Layer 3 Security to Web Passthrough.  Note that you also have the ability to require web passthrough users to give you their e-mail address, but it doesn't validate it is a real address.

Once you click Apply you will be back to the WLANs list page.  On the right side of the page there is a blue box with a white down arrow next to the WLAN profile we created.  Hover over it and choose Mobility Anchors.  Once you're in that page you will choose the IP of the foreign anchor controller from the drop down and then click Mobility Anchor Create.

This completes the configuration of the local WLC.


Configure the Anchor Controller


Login to the anchor controller and click on WLANs and then Create a new WLAN profile just like the one on the Local Controller above except that the ingress interface is None and don't click enabled.  Once you click apply, go to the mobility anchors for the new profile and make sure the Switch IP Address is set to (local) and click mobility anchor create.  Once you have done this, you can go back to the profile screen and check enabled.  


Wrap Up


This article is a rather whirlwind how to of setting up a guest wired network using the Cisco Wireless LAN Controllers.  There are many intricacies not discussed here, but there are plenty of good documents on Cisco's website about how to configure the WLCs.  I do have a question for anyone from Cisco or a wireless guru.  If you have multiple WLCs on the local LAN, can you have the same wired guest vlan piped to all of them or do you have to have a different vlan for each controller?  If you can have the same vlan, how does the traffic know which controller to associate with?