Wireless Access

Hello,

My customer’s requirements for a lightly managed PSK network for residents mean they are looking to allow L2/L3 traffic between a set of registered-ownership devices (registered in CP:Guest), but not allow other users to communicate with it. This is for security reasons and for passing a pen test. I can think of a few ways to accomplish this:
1. Create a VLAN/subnet for each user, and plop all of their devices into the same VLAN. ACLs written to allow only a little traffic within their subnet, somehow, and the internet.. Not very scalable for this environment. They will have hundreds of unique users, and changing.
2. Create downloadable user roles (DUR) from ClearPass that creates the user-role identifying the user. Then also pass back rules that allow the right traffic between those same-user roles, and deny the rest to the same subnet. I can see this handling L3, but not L2. I’m not 100% on the scalability of this, nor if the ACLs can be written this way - I will lab it this morning. The DUR writing could also get a little hairy.

What I can’t do:
3. Turn on deny-inter-user-traffic : they need and use AirGroups on the same network. AirGroup works for the discoverability part, but not a malicious actor trying to compromise devices.

Thoughts? Best practices?

Just curious if anyone saw this and had any thoughts?

---------------------------------
ryh
---------------------------------



Original Message:
Sent: Jan 25, 2023
From: ryh
Subject: ACL Writing: allow role-to-roles, deny others

Hello,

My customer’s requirements for a lightly managed PSK network for residents mean they are looking to allow L2/L3 traffic between a set of registered-ownership devices (registered in CP:Guest), but not allow other users to communicate with it. This is for security reasons and for passing a pen test. I can think of a few ways to accomplish this:
1. Create a VLAN/subnet for each user, and plop all of their devices into the same VLAN. ACLs written to allow only a little traffic within their subnet, somehow, and the internet.. Not very scalable for this environment. They will have hundreds of unique users, and changing.
2. Create downloadable user roles (DUR) from ClearPass that creates the user-role identifying the user. Then also pass back rules that allow the right traffic between those same-user roles, and deny the rest to the same subnet. I can see this handling L3, but not L2. I’m not 100% on the scalability of this, nor if the ACLs can be written this way - I will lab it this morning. The DUR writing could also get a little hairy.

What I can’t do:
3. Turn on deny-inter-user-traffic : they need and use AirGroups on the same network. AirGroup works for the discoverability part, but not a malicious actor trying to compromise devices.

Thoughts? Best practices?

note that for PSK  auth, clearpass/RADIUS server does not come into picture.
See if "Deny Intra-VLAN Traffic" works for your case
https://www.arubanetworks.com/techdocs/Instant_86_WebHelp/Content/instant-ug/services/clientisolation.htm

------------------------------
If my post was useful accept solution and/or give kudos.
Any opinions expressed here are solely my own and not necessarily that of HPE or Aruba.
------------------------------

Original Message:
Sent: Jan 25, 2023 09:21 PM
From: ryh
Subject: ACL Writing: allow role-to-roles, deny others

Just curious if anyone saw this and had any thoughts?

---------------------------------
ryh

Original Message:
Sent: Jan 25, 2023
From: ryh
Subject: ACL Writing: allow role-to-roles, deny others

Hello,

My customer's requirements for a lightly managed PSK network for residents mean they are looking to allow L2/L3 traffic between a set of registered-ownership devices (registered in CP:Guest), but not allow other users to communicate with it. This is for security reasons and for passing a pen test. I can think of a few ways to accomplish this:
1. Create a VLAN/subnet for each user, and plop all of their devices into the same VLAN. ACLs written to allow only a little traffic within their subnet, somehow, and the internet.. Not very scalable for this environment. They will have hundreds of unique users, and changing.
2. Create downloadable user roles (DUR) from ClearPass that creates the user-role identifying the user. Then also pass back rules that allow the right traffic between those same-user roles, and deny the rest to the same subnet. I can see this handling L3, but not L2. I'm not 100% on the scalability of this, nor if the ACLs can be written this way - I will lab it this morning. The DUR writing could also get a little hairy.

What I can't do:
3. Turn on deny-inter-user-traffic : they need and use AirGroups on the same network. AirGroup works for the discoverability part, but not a malicious actor trying to compromise devices.

Thoughts? Best practices?

Thank you for the reference. Unfortunately, due to the use of AirGroup the deny-intravlan feature will not be applicable for this case.

The use of ClearPass in our case is to derive the user role for the devices that have been pre-registered in the ClearPass Guest pages. It is there I hope to determine if DUR may solve my need, or if ACLs or some other mechanism I have not considered may be better. AirGroup with CPPM device registration has been working as intended for the zeroconfig discovery filtering part.

I feel there should be a way to do what the client wants, but I am having difficulty envisioning exactly *how*. Any thoughts or criticisms are welcomed!

---------------------------------
ryh
---------------------------------



Original Message:
Sent: Jan 25, 2023
From: ariyap
Subject: RE: ACL Writing: allow role-to-roles, deny others

note that for PSK  auth, clearpass/RADIUS server does not come into picture.
See if "Deny Intra-VLAN Traffic" works for your case
https://www.arubanetworks.com/techdocs/Instant_86_WebHelp/Content/instant-ug/services/clientisolation.htm

------------------------------
If my post was useful accept solution and/or give kudos.
Any opinions expressed here are solely my own and not necessarily that of HPE or Aruba.
------------------------------

Original Message:
Sent: Jan 25, 2023 09:21 PM
From: ryh
Subject: ACL Writing: allow role-to-roles, deny others

Just curious if anyone saw this and had any thoughts?

---------------------------------
ryh

Original Message:
Sent: Jan 25, 2023
From: ryh
Subject: ACL Writing: allow role-to-roles, deny others

Hello,

My customer's requirements for a lightly managed PSK network for residents mean they are looking to allow L2/L3 traffic between a set of registered-ownership devices (registered in CP:Guest), but not allow other users to communicate with it. This is for security reasons and for passing a pen test. I can think of a few ways to accomplish this:
1. Create a VLAN/subnet for each user, and plop all of their devices into the same VLAN. ACLs written to allow only a little traffic within their subnet, somehow, and the internet.. Not very scalable for this environment. They will have hundreds of unique users, and changing.
2. Create downloadable user roles (DUR) from ClearPass that creates the user-role identifying the user. Then also pass back rules that allow the right traffic between those same-user roles, and deny the rest to the same subnet. I can see this handling L3, but not L2. I'm not 100% on the scalability of this, nor if the ACLs can be written this way - I will lab it this morning. The DUR writing could also get a little hairy.

What I can't do:
3. Turn on deny-inter-user-traffic : they need and use AirGroups on the same network. AirGroup works for the discoverability part, but not a malicious actor trying to compromise devices.

Thoughts? Best practices?