Sequence: Here starts the order that ACL lines are processed against the packet. Even after creation of ACL with sequence number 1, we can replace it with new sequence. Means it also allows us to insert ACL lines anywhere in the ACL even after the ACL is created.

Source IP & Destination IP: Here we have to enter the host or subnet IP and mask (From & To, The masks of the ACL are not wild-masks but normal masks).

Protocol:We need to enter the Protocol to add this in IP packet header.

Here is the list of all which we can use: Any (all protocol numbers are matched)

Any: Sourced from the wireless client and destined to the wireless client are inspected to see if they match the ACL line. We must apply to both Inbound & Outbound directions.

Action:Either Permit or Deny

Rules:

We can only specify protocol numbers in the IP header (UDP, TCP, etc…) in ACL lines, because ACLs are restricted to IP packets only.

If the source AND destination is any, then the direction is also ANY.

If the source or destination is NOT any, then the direction must be specified.

The direction is faced FROM the controller.

Inbound: Wireless client To WLC

Outbound: WLC To wireless client

Remember that at last we have an implicit deny at the end.

Let’s start doing configuration.

First we will create an ACL and apply to either WLAN or Interface.

Login to WLC then Security> Access Control lists > Access Control lists, click on New.

Also check theEnable counter to see the statics.

CPU Access list

In my example:

Block Telnet from a specific workstation on management interface

Workstation: 192.168.128.8WLC2: 192.168.10.3

Create Access List and Apply it.

*** To remove this ACL either we have to uncheck “Enable CPU ACL” box or Via CLI we must use this command”config acl cpu none”. Remember this command if we stuck into the case where we can’t access WLC anymore then via console run this command to get the access back.

*** LWAPP/CAPWAP control traffic is not affected by CPU ACLs.

***By default Telnet is disabled on WLC, we must enable it for testing.(From Management > Telnet-SSH)

In this post we will learn about the AAA override feature which is used with ACS (Radius Server).

This AAA Override function used to configure for identity networking. It allows us to configure VLAN tagging, QoS and ACL for specific clients.

Basic Info:

By using this feature we can reduce or minimize WLANs and can provide or segregate network segmentation within the network.

IN this post we take an example especially for dynamic VLAN assignment. This feature allows a single SSID to serve multiple users as per their roles (as per their VLANs).

How it works:

Wireless client associates to the AP on specific WLAN.

Wireless Client start RADIUS authentication process.

When the wireless client authenticates successfully, the RADIUS server assign this client to a specific VLAN (as we configured on RADIUS server), regardless of the VLAN assigned to SSID the client is using on the AP. If the RADIUS server does not return any VLAN attribute for the wireless client, the client is assigned to the VLAN specified by the SSID mapped locally on the AP.

Limitation:

To apply an ACL we must disable & then enable the WLAN so that client must re-authenticate again otherwise ACL does not take effect.

If we don’t have ACL on WLC or put the wrong name, then the clients are not allowed to be authenticated.

In HREAP/Flexconnect local switching, Multicast is forwarded only for the VLAN that the SSID is mapped to and not to any overridden VLANs.

When the interface group is mapped to a WLAN and clients connect to the WLAN, the client does not get the IP address in a round robin fashion. The AAA override with interface group is supported.

AAA override is done at the RADIUS server.

On WLC, enable AAA Override parameter using the GUI or CLI. Enabling this parameter allows the controller to accept the attributes returned by the RADIUS server. The controller then applies these attributes to its clients.

Enable this feature on WLAN:

Via GUI:

Via CLI:

WLC > config wlan aaa-override enable <wlan-id>

In next post we will see how this function can be used with an example.

In this post we will learn about how to configure the foreign mapping between 2 controllers.

Auto-Anchor mobility, also known as Foreign Mapping, allows us to configure users that are on different foreign controllers from different physical location to obtain IP addresses from a subnet or group of subnets based on their physical location.

First of all Both controller must have added each other in its mobility list.

In this post we will learn how to setup an Office extend AP. In my example I am using the normal AP (2600 series).

Basic Info:

As its name indicates, it “extends” our wireless network to a remote home office. It provides to remote home workers with the same type of enterprise access they’d get within the corporate office.

Cisco has specific APs for this use and that’s oEAP600:

The Aironet 600 is a simultaneous dual-band access point providing both 2.4 and 5 Ghz radios. Hooks noted that by having a simultaneous radio, one can be used for personal use, while the other can be dedicated for corporate access, using separate SSIDs.

Cisco has released special Access Point series (OEAP 600 series) have 4 LAN ports. One port is for Remote-LAN, other 3 ports are for local LAN connectivity. For the corporate WLAN extended, max of 3 WLAN can be extended & max of 15 clients can be joined. Configuration wise OEAP is only requires WLC IP to be pre-configured.

OEAP tunnels back to a Cisco WLC with an IPsec VPN tunnel. One more interesting is it keeps enterprise access and authentication extended across the VPN without the need for any addition configuration. OfficeExtend AP requires an internal Cisco Wireless LAN Controller.

As per Cisco best practices and proper security we need 2 WLCs (DMZ & Internal). 2nd WLC is normally placed into DMZ and must have a NAT address assigned to it with ports UDP 5246 and 5247 open to it.

We just need to prepare the AP with the public address set on the WLC and connect to our Fritzbox or DSL router. Once the AP comes up then we can use our corporate networks with all of their security requirements, without any VPN connection.

Remembering Points:

Before connection to Frtiz box or DSL router it must be primed with WLC IP.

Then connect the AP to Fritz box / DSL router and gets an IP address, joins to primed controller and it creates encrypted DTLS tunnel. Then we can use the all SSID which we normally used in our Office.

We must enable the NAT on our WLC with correct IP address by using this command:

config network ap-discovery nat-ip-only enable

Configuration Guide:

I am using the 2600 series AP (At the moment CCIE LAB don’t have OEAP600 series)

In my case first I joined the AP to WLC as local mode. Once it’s connected we must have to change to Flexconnect/HREAP mode.

Wireless> All APs, select specific AP which we want to convert then go under Generaltab, select FlexConnectmode, click Apply. After that it will reboot.

Once it will come up as Flexconnect mode, we can see that there is one more tab “FlexConnect”.

Now to convert it to OEAP mode we must check Enable OfficeExtend AP box.

Just after selecting the box we can see that there are two prompts:

Do you want to enable encryption –> SelectOK

Do you want to disable Rouge Detection –> SelectOK

***If we choose the encryption enable then all traffic will be encrypted. (DTLS)

In my case I don’t have right license for DTLS so can’t encrypt this Tunnel.

If want then we can also broadcast the specific WLANs from HQ to this by creating AP groups otherwise by default it will be default-group.

Other Info:

By default, the WLC will only respond with the NAT IP address during AP Discovery when NAT is enabled. If APs exist on the inside and outside of the NAT gateway, issue this command in order to set the WLC to respond with both the NAT IP address and Non-NAT (inside) Management IP address:

In this post we will learn how to implement wired guest access with only one WLC.

A single WLAN controller (VLAN Translation mode) – the access switch trunks the wired guest traffic in the guest VLAN to the WLAN controller that provides the wired guest access solution. This controller carries out the VLAN translation from the ingress wired guest VLAN to the egress VLAN.

Here is my Topology:

To provide the wired guest access, the ports in the Layer 2 access layer switch must be configured on the guest VLAN. The guest VLAN must be separate from any other VLANs that are configured on this switch. The guest VLAN traffic is trunked to the nearest WLAN local controller.

In the interface configuration page, check the “Guest LAN” box. As soon as we check this box, fields such as IP address or gateway disappear. The only thing your WLC needs to know about this interface is that “there will be client traffic coming from VLAN 999.

Step2: Configure a normal dynamic interface in which we want to assign IP to guest. (Egress)

Create another dynamic interface where the wired guest clients receive an IP address.

In this example we have VLAN 17 for clients to get IP address named as guest.

Step3: Create a wired LAN for guest user access.

Add a new WLAN: Type must be “Guest LAN”

WLAN> WLANs, and then Create New WLAN.

Enable the WLAN; map the ingress interface to the “vlan999” created in Step 1, and the egress interface to guestinterface created in Step 2.

***Remember that Layer2 security is not supported in Wired LANs.

Then we will select layer 3 web authentications.

Here I am using Customized web auth.

Step 4: Create a local test user to testing.

Security> AAA> Local Net Users

That’s it for the configuration.

Step 5: Verification

Testing time:

Now we should connect a Laptop/PC to port Fa0/10 which is in VLAN 999 and see what happens there. I got the IP in VLAN17 (Guest interface): 192.168.17.5

If you have correct DNS resolution then a pop webpage will appear otherwise we have to manually open our WLC virtual interface (https://1.1.1.1/login.html). There we have to use the credential created in Step 4.

If WLC is configured with management users both locally & RADIUS server with the Management check box enabled. In this case, by default, when a user tries to login to the WLC, the WLC behaves in this manner:

First looks at the local management users. If the user exists in its local list, then it allows authentication for this user. If this user does not appear locally, then it looks to the RADIUS server.

Means WLC always takes precedence when compared to the RADIUS server.

Authentication Oder for management users on the WLC.

Security> Priority Order > Management User.

*** If LOCAL is selected as second priority, then the user will be authenticated using this method only if the method defined as the first priority (RADIUS) is unreachable.

Verification

To verify each account, we must login with different users and check it.

If we login with user (sandeeprw) then we will have full administrative access to the WLC.

Example: If we login with read only user (sandeepro) and want to modify something on WLC then this will appear: