howto block p2p traffic of clients connected to the same ssid on different wlc

Unanswered Question
Feb 3rd, 2010

Hi all,

I use two wlc 4400 (4.2.x version) with a mobility domain and one ssid, both wlc are connected to a cisco l2 switch infrastructure. On the wlc I use the p2p blocking action 'drop' (http://www.cisco.com/en/US/docs/wireless/controller/5.2/configuration/guide/c52wlan.html#wp1209597) to isolate the clients from each other. Does anybody know if only unicast traffic is blocked or also multicast and broadcast traffic like arp requests?

Concerning blocking p2p traffic of clients connected to the same ssid but different controllers I found the following statement in the LAP FAQs (http://www.cisco.com/en/US/products/hw/wireless/ps430/products_qanda_item09186a00806a4da3.shtml):

===

Q. In autonomous APs, Public Secure Packet Forwarding (PSPF) is used to avoid client devices associated to this AP from inadvertently sharing files with other client devices on the wireless network. Is there any equivalent feature in Lightweight APs?

A. The feature or the mode that performs the similar function of PSPF in lightweight architecture is called peer-to-peer blocking mode. Peer-to-peer blocking mode is actually available with the controllers that manage the LAP. If this mode is disabled on the controller (which is the default setting), it allows the wireless clients to communicate with each other through the controller. If the mode is enabled, it blocks the communication between clients through the controller. It only works among the APs that have joined to the same controller. When enabled, this mode does not block wireless clients terminated on one controller from the ability to get to wireless clients terminated on a different controller, even in the same mobility group.

===

Does anybody know what's the best practise to prevent this inter wlc client traffic? I already read about using acls on the wlc dynamic interfaces, or private vlans on the l2 switch vlans where the dynamic interfaces are connected to. Is it allowed to completely isolate the wlc from each other on these dynamic interfaces with acls or private vlans or do the wlc need to see each other on this interfaces (e.g. heart beat)?

Many thanks in advance,

Thorsten

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
SashaTchepourko Thu, 10/27/2011 - 17:43

Hi Thorsten,

Did you get an answer to your question? - "Does anybody know what's the best practise to prevent this inter wlc client traffic?"

I've been using interface ACLs but it's impacting users' performance.

surbg Thu, 10/27/2011 - 17:49

No!! Its the WLC in picture... it works for same controller and APs registered to the same and P2P blocking the clients connecting to it on a WLAN

SashaTchepourko Thu, 10/27/2011 - 17:54

When you say it works - are you talking about P2P Blocking Action or Dynamic Interface ACLs?

thorsten.steffen Thu, 10/27/2011 - 23:21

We're still using acls on the dynamic interfaces which is working fine although it isn't a preferred solution. Did you test Forward-UpStream? Did it work?

Thorsten

nikhilcherian Thu, 10/27/2011 - 23:51

There was a bug on this issue in 7.0.116.0 that the WLC was not forwarding the upstream traffic with Forward Upstream enabled. Not sure if this was resolved

Thanks

NikhiL

SashaTchepourko Fri, 10/28/2011 - 01:20

I've been using interface ACLs as well however I've disovered today that they impact users' performance. Having them on can only pull down ~9Mbps. With it off getting ~50Mbps. The way that I found the issue was with a VNC session, very slow to refresh, but the second I take the ACL off it's all good.

Forward-UpStream doesn't seem to work (or parts of it). It seems that there are two things now working for me:

1. ARPs are being dropped if a client A queries client B's MAC (ok if client queries gateway's MAC)

2. Traffic is sent upstream, ie. router sees client's A packet and sends it down, as a simple permit any any log outbound ACL sees hits, but that packet never reaches the client B. (this was done with static arp entries on the machines).

Hope this makes sense.

NikhiL, do you know what was that bug id?

saprabhu Fri, 10/28/2011 - 21:47

Hi Sasha,Thorsten

The bug is Junked and I believe which is what you are running into with your tests:

CSCtr60787    WLC P2P Blocking Set to Forward-UpStream Doesn't Work.

Bugtoolkit : http://tools.cisco.com/Support/BugToolKit/action.do?hdnAction=searchBugs

To answer your original query :

ACL is only solution to block client communication on same ssid between 2 wlcs. 5508 works better with ACLs then 44xx platform.

ARP requests will be forwarded to upstream router just like any other traffic. WLC won't proxy arp for clients on same vlan.

Gateway arp's I believe should be handled by WLC . ( Don't quote me on this but I am pretty sure it is ) ..If it was not, then how would client know about gw ?

Multicast traffic is not applicable for p2p.

Your ACL can be as simple as this for the scenario :

WLC 1 - clientvlan = 10
WLC 2 - clientvlan = 10
and you want to restrict users from wlc1-wlc1, wlc1-wlc2, wlc2-wlc2 for same vlan10.

Basically in that case the ACL should look like on both WLCs :
1. Permit statement to talk to gateway.
2. Deny to subnet.
3. Permit all.
4. If DHCP/DNS other services are on same subnet then you would need to add a permit
statement before the deny.
5. Attach the ACL to SSID or dymanic interface.


Thanks..Salil

CSCtr60787    WLC P2P Blocking Set to Forward-UpStream Doesn't Work.
SashaTchepourko Tue, 11/01/2011 - 23:32

Hi Salil,

Thank you for the information.

I'm currently using the ACL on the Dynamic interface but have found that it imacts our clients' performance.

Any ideas why? I'm have 5 WiSM blades in total all doing the same thing.

saprabhu Wed, 11/02/2011 - 06:38

Hi Sasha,

Yes Performance will be impacted as ACL's on WLC are software based..whereas on Router/Firewalls they are Asic/hardware based ( so fast ).

Longer the ACL, the slower it will be.. Try to put packets which HIT most at the beginning .. Use ACL counters to determine which Statement is HIT most often.

Thanks..Salil

SashaTchepourko Wed, 11/02/2011 - 16:36

Salil, again thank you for the information. That's I thought as well. Unfortunatelly in my environment the ACL is already as small as it can be.

Would you know when the Forward-UpStream feature will be fixed? As we need the functionality of filtering the p2p traffic but don't want the solution to impact our clients' performance.

Regards,

Sasha.

thorsten.steffen Thu, 11/03/2011 - 02:25

Sasha,

if your wlc are connected via cisco switches perhaps private vlan feature is a possibility to prevent client-to-client traffic being transferred between wlc. We thought about this solution last year but private vlans weren't supported on vlan trunks at this point of time; in current ios versions it's supported on vlan trunks.

Regards,

Thorsten

saprabhu Thu, 11/03/2011 - 13:04

Sasha,Thosten

As far I know p2p over multiple ssid is not planned to be fixed. You can approach your account team to address this as PERS ( Product enhancement request ) but they would need to have good buissness justification $$ and number of customers requesting the feature..

I have not tried Private vlans ..Sorry..May be if I get some time I will test out.

Thanks..Salil

pzpgd1mlf Sun, 09/02/2012 - 14:21

Hello there, did we ever got an answer on this? Still wondering if private vlan is the way to go or perhaps protected ports, which may not bring scalability in a large wireless network.

mike.burk Thu, 01/10/2013 - 15:18

I too would like to know if a best practice has ever been discovered for this.

I have a site that has 550 APs with 4 x 5508 so I have use multiple controllers at this site.

Thanks in advance.

thorsten.steffen Thu, 01/10/2013 - 23:59

We're still using acls on the dynamic interfaces, not nice but it's working fine in our environment (6 wlc).

Best Regards

Thorsten

mike.burk Fri, 01/11/2013 - 09:03

Very good, can you provide some sample ACL lines so we can see how that would look?

In my case the controllers are connected via Layer2 and I'm not sure the L2 traffic of a client on Controller1 would hit the SVI before being switched to a given client on Controller2.

thorsten.steffen Mon, 01/14/2013 - 06:53

config example on wlc44xx:

wlan client net: 10.1.1.0 /24, default gateway 10.1.1.10 (dedicated router in our case)

acl rules:

1. 10.1.1.0 /24 -> 10.1.1.10: Permit
2. 10.1.1.10 -> 10.1.1.0 /24: Permit
3. 10.1.1.0 /24 -> 10.1.1.0 /24: Deny
4. 10.1.1.0 /24 -> 0.0.0.0 /0: Permit
5. 0.0.0.0 /0 -> 10.1.1.0 /24: Permit

in short words: Allow Traffic to/from default gateway + deny traffic inside the net + allow traffic to/from rest

Actions

Login or Register to take actions

This Discussion

Posted February 3, 2010 at 5:52 AM
Stats:
Replies:19 Avg. Rating:
Views:11658 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard