Wireless Access

We want to do a wireless setup as follows:

We have a Aruba 7005 wireless controller with multiple 205 access points.
We have 1 'internal' SSID (bridges to the local LAN) and 1 'guest' SSID (seperate VLAN, tunnels to the controller).

We have wireless presentation systems (wepresent) connected to the wirelress guest network ( as wifi clients) and customers can connect to the guest network with their notebook and auto-discover and use the presentation system (auto-discovery is possible when in the same VLAN).

The problem is that all the traffic between clients on the same SSID on the same Access point is doing a round trip to the controller. In our main (HQ) office this is not a problem (our controller is located here). In the remote offices we want to do the same setup but we can't make the traffic make a round trip because of a slow line between the branch office and the HQ office.

Does somebody know if there is a possibility to let clients on a tunneled SSID talk to each other without traffic going up and down the line to the controller? And if so, how to do this?

regards.

The problem is that we can't use bridge mode for the 'guest' network because we need to tunnel it to our HQ office.

I already tried the decrypt tunnel but without succes. Traffic still does a round trip to the controller.

You could make your AP a Remote AP, make the VAP split-tunnel, but make the ACL for the role "allowall" to simulate a tunneled SSID.  You would then turn on "Rap Local Network Access"

 http://www.arubanetworks.com/techdocs/ArubaOS_64x_WebHelp/Web_Help_Index.htm#ArubaFrameStyles/Remote_AP/Advanced_Configuration_O1.htm?Highlight=RAP Local Network Access

The idea is that making an AP a RAP and having the VAP as split tunnel, will push the firewall to the RAP, where it can make routing decisions, because the traffic is decrypted.  Turning on RAP local network access will allow it to make decisions based on devices that are connected to that RAP.

Thanks! This works.

Only one new problem: the throughput from the 205AP to the controller is 8Mbps and from the controller to the AP 12Mbps. Is this normal behaviour when using RAP (VPN tunnel).

regards 

What is between the AP and the controller?

At this moment a Gigabit LAN (i did the setup in the internal network of our main office, later on we will use the tunneling from an AP in a remote office to the controller in the HQ office).

Controller is a 7005

I did not created any ACL, interclient communicatio without tunnel roundtrip is working 'out of the box' when enabling the RAP and choosing split-tunnel.

Is that over wireless or wired?  Are you using "Drop broadcast and Multicast" on that VAP?

There is a wired gigabit connection between the AP and the controller. When using GRE tunnel from the AP to the controller, speed is almost as high as the 802.11n speed. when using the 'special' VPN setup (remote ap), speed is as low as 12Mbps.

I did not choose the option to 'drop broadcast and unknown multicast' because we need it.

Again, what client are you using to do the speedtest?  Is it a wired or wireless client?  If it is wireless, do you have "Drop Broadcast and Multicast" Enabled on that SSID.  Depending on the AP, there is a limit to the speed over ipsec, because of the overhead.  It is typically expected that a RAP is over a WAN connection, so typically that is expected.  If you want clients to be able to talk to each other and you still want this arrangement, you might want to consider bridging the user traffic to a VLAN that is local to the AP where the clients can talk to each other.

I'm doing the speedtest to a wired client on the same VLAN as the tunneled SSID VLAN. 

I did a few extra tests and the speed problem has to do with the split tunneling, not with the RAP VPN tunnel.

When using RAP VPN with decrypt tunnel (instead of split tunneling) the speed goes back to its maximum, but then i loose the possibility of interclient communication without controller roundtrip.

So i realy need the RAP with split tunneling setup.. but with full speed.

I guess it has something to do with routing or ACL's (i think some packets are wrongly routed and causing the slow speed)