Security

Hi community,

My customer has a Cisco wired and wireless network. It has around 8 SSIDs with different VLANs, and all the network access control is made at the core switch (where all the VLANs end up) with ACLs.
Recently he has renewed the wireless network with Aruba APs and has also acquired ClearPass for controlling the network access. Now I will use profiling and roles to reduce the number of SSIDs as much as possible, but how can I achieve to control the network access with ClearPass when actually all this control is managed at the core switch throughout ACLs? Do I have to use the ClearPass roles and send them to the Aruba controller as usual, create the firewall ACLs in the controller and remove the current ACLs from the core switch? Is that the way? Because if so, I just moving the ACLs from the core switch to the Aruba controller. Is there another way?
And that's for the wireless part, how can I control the network access for the wired devices? Because the current ACLs in the core switch control both wireless and wired traffic. For the wired part, do I have to integrate all the access Cisco switches with ClearPass and push ACLs to them from ClearPass?
Any answer will be much appreciated!

Regards,
Julián

Hi,

 

Any idea?

 

Regards,

Julián

Hi Julian,

 

all szenarios you describe are possible. Of course some are not the optimum solution.

 

Just adding ACLs to controller and leaving them on core switches will be secure, but WIFI traffic will be filtered two times.

 

Adding to controller and dropping ACLs from core without changing anything else will drop security for wired clients.

 

----------------------------

 

I prefere to have seperate VLANs for wired and wireless. That way you can filter wired at core and wireless at controller. But I try to omit filtering at core (see below...)

 

For me, the rest is on how you like to operate this.

DUR for Controller on CPPM will save operational burdon.

 

Not sure, since I have no experience with CPPM and Cisco switches. But I guess DACLs for Cisco would work with CPPM too. You could move wired ACLs to access switches and save operational burden like with DUR and wireless...

 

So I would try that route:

- separate wifi to a different VLAN

- use DUR for wireless

- filter wireless only at controller, not at core.

 

If customer is willing to do this:

- authenticate users/devices at access switches

- assign ACLs to sessions at access layer, if possible use DACLs

 

If above is done:

- drop filters from core switches

 

A lot of this is just my opinion. Others might decide different...

 

Regards, Jö

 

 

Hi Jö,

 

When you say:

 

DUR for Controller on CPPM will save operational burdon.

 

Not sure, since I have no experience with CPPM and Cisco switches. But I guess DACLs for Cisco would work with CPPM too. You could move wired ACLs to access switches and save operational burden like with DUR and wireless...

 

Do you mean lighten the burden of ACL proccesing on the core switches?

 

Regards,

Julián

When wired and wireless are separated, the core switch only needs to apply acl to the wired part.
Wireless can be applied in the controller

Hi Julian,

 

no, I was talking about "human operational burdon for configuration and troubleshooting".

 

Lets say, you have 50 access switches. If you use old style way, which is to send the ID or name of an ACL to the NAS, then you have to configure the same ACL on all 50 switches. A lot of burdon, if you do not have a management solution like prime or IMC.

 

With downloadable ACLs (not sure if Cisco names it dynamic or downloadable...), the ACL is configured at the policy server. Thus, you need only configure it once.

Afterwards, either the ACL is send to the NAS (e.g. old procurve style) or the NAS is told to download the ACL. Both is done by sending specific RADIUS attributes.

 

So this saves you the work, to keep an ACL consistent accros a lot of NAS devices.

 

With Aruba Controllers, Instant APs and ASOS Switches (former Procurve, new firmware, new aaa model), the settings are collected in a user Role. You can either send the name of a role to NAS or you can tell NAS to download the user role (downloadable user role -> DUR).

If you use Mobility Master, configuration can be inherited by different controllers. So the burdon is not too big to configure roles. But I prefere to have one place to hold these configurations.

Clearpass is prepared and has some nice forms to configure DURs for controllers and switches.

 

So I'd use DURs.

As said, I guess, that Cisco dACLs are possible, but have no experience...

 

Regards, Jö

Hi Jö,

 

Great explanation, many thanks for your help!

 

But when you say:

 

Lets say, you have 50 access switches. If you use old style way, which is to send the ID or name of an ACL to the NAS, then you have to configure the same ACL on all 50 switches. A lot of burdon, if you do not have a management solution like prime or IMC.

 

As I said at the beggining of the post, currently all the network access control is made at the core switch (where all the VLANs end up) with ACLs. So, he doesn't configure ACLs in many access switches, just in one switch, both for wired and wireless traffic. Currently, he doesn't use roles, and with ClearPass, the WLC and DUR I will be able to use roles and have a more granular network access control. But besides this, what is another benefit of using ClearPass for network access control instead of ACLs at the core switch? Finally, all the current ACLs are configured on the core switch, just on one device, so the network access control is hold centralised at one place as well.

 

Many thanks again,

Julián

Why let traffic traverse the network just to get blocked at the core?

 

Core switches are designed for high speed switching and routing, not access control.

yeah,  that was what I learned in ancient procurve days. Command to the center and control to the edge :-)

 

Enforce your policies as far out to the edge as possible.

 

Per user ACLs are smaller and easier to understand than long VLAN/Router ACLs at core layer.

 

Another aspect is stability at core level. Change as seldom as possible. Config failures can cause core outage. Features not needed at core level can cause crashes. lengthy core config leads to more dificulties while troubleshooting core layer.

 

And so on.

 

All more weak facts. But I follow them if I can...

 

 

By the way, I receive a lot of "You accepted as solution..." messages since two days. But I didin't accept. Did someone else in this thread accept? Would mean, the email notification is missleading. Or is something going wrong at my end?

Have opened a case with airheads support. We'll see...

Want to be recognized as behaving correctly in this community and not as "he accepts everything as solution guy..."

 

Best regards, Jö

 

 

Hi guys,

 

Many thanks for your replies, it makes a lot of sense. Much more clear!

 

By the way, I receive a lot of "You accepted as solution..." messages since two days. But I didin't accept. Did someone else in this thread accept? Would mean, the email notification is missleading. Or is something going wrong at my end?

Have opened a case with airheads support. We'll see...

Want to be recognized as behaving correctly in this community and not as "he accepts everything as solution guy..."

 

Yeah, the same happened with me, I received a lot of mails that say you accepted some of my answers as solution. In fact, this thread has many accepted solutions. There is something wrong with the Airheads system...

 

Regards,

Julián