Cisco OfficeExtend (OEAP) Firewall Rules

I remember I had some dramas getting the OfficeExtend APs initially set up, so here are the firewall rules you need to get the Cisco OfficeExtend access points (OEAP) working. The setup assumes you have a DMZ controller which will have mobility anchors into the internal or “Inside” controller.

Internet -> “DMZ” WLC
UDP 5246/5247   (for OEAP communication)

DMZ Controller <-> Inside Controller:
UDP 16666/16667 Bidirectional to “Inside” WLC and “DMZ” WLC
IP Protocol 97 Bidirectional to “Inside” WLC and “DMZ” WLC

DMZ Controller -> Inside Controller:
UDP 1812/1813 to RADIUS Server

Inside Network -> DMZ Controller:
TCP 80/443  (for http/https access)
TCP 22 (for SSH access)

If you have a Wireless Control System server (WCS) or Cisco NCS Prime -> DMZ Controller:
UDP 69  (for TFTP)
UDP 161 (for SNMP)

I spent some time a year or so back getting it going and it has been a good solution for extending the corporate wireless lans to wherever it is required. Obviously, security should be of concern so at least ensure you are securing the WLANs using certificates, RADIUS and AD authentication (WPA2 Enterprise) at minimum.

In my case the 602 model AP can provide 2 WLANs as well as a “Remote LAN” connection which I use to plug in a Cisco IP phone for those that want a hard phone coupled with the AP. Be careful of the remote lan port – it essentially is a port that is tunneled straight onto your inside network (which is why the phone works).

Google Blake Krone’s 602 AP review for more detail on the OEAP setup – he helped me out a lot and could not have done it without his assistance….thanks Blake!

Office Extend Setup

OfficeExtend setup – clear as mud now? :)

Cisco ACE context erasing

One of the most annoying things I found out about the ACE module was that I couldnt just ‘write erase’ a context from within it. For example, lets say I just wanted to erase the current config and paste in a new one because of massive changes or I’ve got a test context that changes a lot etc….well I couldnt find an easy way to do it.

What I do now to overcome this is use checkpoints. When I create a brand new context; the first thing I do is create a checkpoint – a blank one:

checkpoint create blankcontext

Then, paste in your new config and if its stable then create a new checkpoint. Checkpoints are also useful for instant rollbacks of any changes – just create a new checkpoint whenever you are about to make changes.

Having the blank checkpoint has come in handy a few times. Note that checkpoints are only visible within the same context – so you need to create them in multiple contexts as appropriate.

Call Manager 7 – admin password recovery

I had a vm for cucm7.1(3) that I’d had off for a while – and I needed to fire it up again for some lab testing. Of course, my usual set of passwords didnt work to get into the thing. So, at the console of the vm, I did the following:

1. Login at the console using username: pwrecovery  password: pwreset.

2. Edit the vm’s settings to ensure no cdrom images or physical cdroms are connected.

3. Follow the prompts, and re-enable the call manager iso image in the cdrom drive when prompted to ‘insert the cdrom’. Its basically asking for the call manager install media.

This resets the user admin account to ‘admin’ with a new password you specify.