Two questions about CPU ACLs

[CSCO11733516]

Guys,

I've read the documents provided by Cisco here, but none have really given me the direct answer I am looking for.  Was hoping that you guys could possibly shed some light.

Do the CPU ACLs have to contain permit entries for Mobility traffic (WLC-WLC) and CAPWAP/LWAPP (WLC-AP) traffic?

Are the CPU ACLs applied to the service-port interface?

[mohanak]

CPU ACLs

Whenever you want to control which devices can talk to the main CPU, a CPU ACL is used. It is important to mention several characteristics for these:

• CPU ACLs only filter traffic towards the CPU, and not any traffic exiting or generated by the CPU.

  Note: For the WLC 5500 series in versions 6.0 and later, the CPU ACL is applicable for traffic originated from the WLC as well. For the other WLC platforms, this behavior is implemented in versions 7.0 and later. Also, when creating CPU ACLs direction fields do not have any impact.

• Full support for CPU ACLs for all controller IP management and dynamic addresses is only present on 4.2.130.0 and later.

• CPU ACLs blocking service port traffic is only present in 5.0 and later.

• When a CPU ACL is designed, it is important to allow control traffic between controllers. The sh rules command can offer a quick view of traffic permitted to CPU ACL on normal conditions.

• The controller has a set of filtering rules for internal processes, which can be checked with the sh rules command. ACLs do not affect these rules, nor can these rules be modified on the fly. CPU ACL takes precedence over them.

• LWAPP or CAPWAP data traffic is not affected by CPU ACLs rules on 4400 based controllers, control traffic is affected (if doing an strict ACL, you need to explicitly permit it).

  Note: CAPWAP control traffic is not affected by CPU ACLs.

[CSCO11733516]

Thank you very much Mohanak for your prompt response.

Upon reading your response, I have question if you can help clarify.  Some may seem redundant, but I just want to make sure I am fully understanding properly.

1.  On the 7500/5500 series WLC's, is CAPWAP control traffic and data traffic subject to being affected by the CPU ACL?

2.  I am familiar with the default internal filtering rules, via the output displayed from the show rules command.  I understand that if a CPU ACL is enabled, it will take precedence over the internal filtering rules.  But does this mean that if a CPU ACL is enabled, that only the CPU ACL will be subject to being checked for traffic designated to the CPU?  Or will it check the CPU ACL first and then proceed to check the internal filtering rules?

3.  I understand that applying a CPU ACL is generally listed by Cisco as a "Best Practice" under the Security portion of both the Cisco Wireless LAN Controller Configuration Best Practices document and the Securing Wireless LAN Controllers (WLC) document, but is this really common to see deployed in real-world Wireless LAN Controllers?

Why would this not be something to apply at the neighboring switch/switchport level?

I just wish that Cisco had a "Best Practice CPU ACL" template/example or something published out there.  To show you the common things you should be configuring in the CPU ACL.

[CSCO11733516]

Thoughts on this?

[Freerk Terpstra]

I agree with you that a better place to protected the controller is on the next hop router / firewall. However, in some cases it is not desirable to use ACLs on core switches for example.

From what I have seen and deployed myself most people just filter on the TCP 22/80/443 access to the CPU and just permit everything else (based on certain IP networks). It really depends on your security policy, architecture and configuration standards what is the most feasible solution for you.

Please rate useful posts... :-)