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?

P@$$W0rD$

As a young naive network admin I thought I could remember everything about everything.  Writing things down, especially passwords, was a waste of time and a security problem.  Well, as things often do, my view on this has come full circle.

Password management is an important part of network documentation.  Without a plan, you end up with two things happening.  First you end up forgetting that rarely used password for the oddball piece of equipment in the back closet of the back room of the building into which no one ever goes.  Unfortunately the day after you forget totally about it, it acts up and you have to get access to it's command line quickly to fix the problem.  Second you end up with a lot of systems having the exact same username and password combination.  This means that when you have to share the password with a technician that doesn't need access normally you will have to reset the password everywhere.  Oh and you do remember everywhere it needs reset right?  

Both of those scenarios were about keeping yourself in the loop, but password management is also important in the event of a loss of personnel.  I often refer to this as the "What if Ben is hit by a bus tomorrow?" information that someone will need to run things if I die or otherwise am no longer at the company.  I really don't want the company sending Jack Bauer into my ICCU room to coerce the passwords out of me while doped up for pain or something.

My solution to managing passwords, both professionally and personally, is to use an application that creates an encrypted file containing all of the passwords.  There are two such software packages (both opensource) that I have used.  The first is PasswordSafe and the other is KeePass.  I personally have settled on KeePass because the application is available for Linux (using Mono), Windows and iOS (Apple, not Cisco).  I have two files, one for work and one for home.  The iPhone app is synchronized manually using a builtin webserver over the phone's wifi connection.  I use Dropbox to synchronize the files between computers.

Cisco Config Rollback and Replacement

In the previous two posts I have outlined how to create a configuration archive and how to compare configurations.  In this post I will look at how to take an archived configuration and use it to replace the current configuration for rolling back changes.  This article assumes that you already have a configuration archive in place.


Before making any changes to the configuration you need to run the command archive command to force IOS to make a backup copy of the current running-config.  Once this is done, make any changes to the configuration.  At this point you've either got a new running-config that you like and that works or you have created a problem and it's time to rollback through configuration replacement.


If you need to rollback the changes, you will need to do the following:

Router# configure replace scp://scpuser:scppasswd@scpserver/configuration1.cfg revert error  time 5
Router#configure revert now
Router#configure confirm

The configure revert now and configure confirm are both optional commands depending on how you configure the replace command and the outcome.  For example if you are sure that you don't want to revert to the previous running-config typing configure confirm will make the change permanent and resets the timer set in the replace command.  In the above example because we set the time 5 part of the command we must issue configure confirm within 5 minutes or IOS will automatically revert to the previous running config.  If you find that you need to revert  immediately to the previous config you run the configure revert now command. 

As you can see, this can be good for making and rolling back changes as necessary.  Theoretically you can also take a configuration file and edit it offline and then copy it back to the device with the changes.  I say theoretically because you have to be very careful to meet the requirements of the IOS Configuration file in terms of indention.