Wireless Access

Hardware used: Four 3600 series controllers in Master/Local mode, two AP 105 access points.

Software: ArubaOS 6.1.3.4.

I'm in the process of bringing up a remote site for the first time where I will not have a controller on site.  My controllers are not plugged in to the public Internet, they are behind a NAT firewall.  I will, however, have a VPN tunnel available to me back to my main site.  The VPN device is pulling triple duty as our site-to-site VPN link, NAT router, and DHCP server, and is connected to our commodity Internet link.  It is then connected to a layer-3 switch that has a few VLANs configured for our various purposes.  I have all functions of the remote site working except for the Aruba APs.  My goal is that the AP105s will come up and receive a reserved DHCP address on our Network Services VLAN, while supplying wifi access via a WPA2 Enterprise secured network on a different VLAN.  I've configured the switch port it's attached to for trunk mode, allowing the two aforementioned VLANs.  

Bonus points - if I could somehow also get our Captive Portal authenticated network in this location as well.  Note, I don't have a license for PEF-NG.

Am I better off setting these two APs up as RAPs, or as Campus APs in bridge mode?  I don't like the idea of having to set up a VPN connection to the controller that will be travelling over a VPN connection to main campus as it is, this seems to be asking for disaster, which is why I thought at first that bridge mode would be the way to go.  However, I've been having a rough time of it trying to get bridge mode up and running.

Thanks in advance for the help of the always awesome Aruba community :-)

You could do either:

1.  Campus in Bridged Mode 

2.  RAP in Bridged Mode

Both scenarios, you would have to make sure:

- Your Virtual AP that you setup has a forwarding mode of "Bridged"

- The VLAN in the Virtual AP matches the VLAN you would want to trunk user traffic to on the ethernet port on the AP

- The "Native VLAN" parameter in that AP group matches the Native VLAN number that the AP is plugged in, so that the AP knows when to tag the traffic from the client above and send it out that port.

Since you already have a site to site VPN, you could just choose option 1 and this would work fine.  Option 2 is mainly if you have a  NAT boundary that the AP needs to cross to connect to the controller.

You could also setup your guest WLAN and have the forward mode as tunneled and have the Captive Portal page and the user traffic tunneled back to the corporate headend, with no issue.

Please let me know if you have any further questions.

Fast question Collin

"You could also setup your guest WLAN and have the forward mode as tunneled and have the Captive Portal page and the user traffic tunneled back to the corporate headend, with no issue."

This is because captive portal is not supported in campus bridge forward mode  right? 

Cheers

Carlos

That is because guest is not supported on bridge mode, period.

heh.... That was fast Collin

Thank you lot  for your time! :)

---

@cjoseph wrote:

- The VLAN in the Virtual AP matches the VLAN you would want to trunk user traffic to on the ethernet port on the AP 

---

 I have the VLAN in the Virtual AP set up as the one I'm expecting user traffic on, just like I would a standard campus AP.  In this case, 1132.  The only difference is that I've not configured the controller to be aware of this VLAN as I normally would, since traffic is not being tunnelled back to it. 

---

@cjoseph wrote:

- The "Native VLAN" parameter in that AP group matches the Native VLAN number that the AP is plugged in, so that the AP knows when to tag the traffic from the client above and send it out that port. 

---

I'm not finding this option at the AP group level.  I found it when configuring the AP in the "AP Installation" link under the Configuration tab, and did indeed set this to the VLAN I expect the AP to utilize, in this case, 20.  However, when consoling the AP, it fails to retrieve an IP from the DHCP server.  I've double checked that if I set a switch port to just this VLAN that an IP is indeed obtained by a device asking for it in the proper subnet.  I suspect this is where my problem lies.  Where in the AP Group configuration am I missing the Native VLAN parameter?

Okay let me expliain you a bit more about this

Collin can correct me later if im worng but thats how i make it work

Let say on the remote site

Let say you got 2 VLANs that goes to the Bridged AP

let say vlan 5 is untagged and vlan 10 is tagged

Scenario 1 Let say vlan 5 is the one that you want users use as the vlan for the wireless okay?

Then on the virtual AP, you can put vlan 1  as is the untagged so it doest matter...

This is true if on under ap system profile, the native id of the vlan is 1 and if that number matches the one on the VAP the traffic will be send untagged on that port, since the paramther by default is always 1 you also set the vlan on the vap on 1 then the trafffic will send untagged on that port.

Scenario 2

But let say you want that ppl use the tagged vlan on the remote site which is 10

I know you dont have created that vlan on your wireless contorller because that vlan does not exist on the central site...

It doesnt matter is does not exist you have to put in the VAP(Virtual AP) vlan 10(it will accept it even if it does not exist) so just put it.

Remenber the Configuration you put in there is downloaded to the Brdiged AP and even if its not tunned back well the ap will get that info which it needed.

The scenario 1 is convenient if you got many small site in which you will bridge the AP but also take in mind it will be convenient just having the AP and the wireless clients on that vlan you dont want to have wired and wireless client on the same vlan... also you can with the penf block traffic of the users so they wont see the Wireless controller if you want.

Now why its convenient? well its because it will make you configure less...rather that if you got a different vlan for each site.  You will just configure every VAP with vlan 1... and thats it...  and yeah you on the remote site might have vlan 20, 30, 40 all untagged on the port of the AP  but since they are untagged and you will use that vlan then i doesnt matter  you still just have to put vlan 1 which is hte default value of the VAP so you configure less..

I hope that helps you

Now this is a question i ask to collin just to be sure

If the vlan 10 exist back in my wireless controller and is used for another AP  let say vlan 10 exist in the wirelss controller for let say a VAP is tunneled back but i also got a vlan 10 on the remote site, i can safety put vlan 10 as the info will be downloaded to the AP and if if not bridged back it will just tell theAP to use the local vlan 10 and if it tunneled back it will use the vlan 10 on the controller rigth?

We went completely in the wrong direction.  My configuration was proper from the start.  I realize now that I neglected to mention that the APs were never getting their IP address, and I do apologize for that.  Normally I try harder to give better information when posting since I know it's a pain to not have all the facts.  Here's a word of warning to anyone else trying to set up a bridged AP on a trunk port:

Don't initially configure it on the trunk port :-)

What happened was that the configuration wasn't properly getting pushed to the AP to tell it the uplink VLAN it belonged to.  On a whim, I moved the AP to a switch port that was set to access mode for the AP's intended VLAN.  The AP got its IP, and came online, though obviously the radios couldn't pass traffic being on an access port.  I plugged back in to the trunk port, and everything worked then.  I noticed the following line that wasn't there before during boot:

net.aruba_asap.uplink_vlan = 20

Now that this shows up, I have no issues and my APs are happy.  So here is what I would advise future users to do:

1. Plug your AP into an access port for the VLAN you intend it to reside on and go to the AP installation tab.
2. Configure it as you would any other AP, but when you get to the IP Settings section, ensure that the Uplink VLAN is the VLAN you intend the AP to communicate on.
3. Click the Apply and Reboot button and ensure the AP comes back up.
4. Plug the AP into the properly configured trunk port and enjoy.

Hopefully this helps future people down this road.

cjoseph:  As for your suggestion to simply tunnel the traffic to the controller, I'll have to run this by my boss.  As the building we're in at the remote site is not ours alone, there are many others that may try to bang on our Captive Portal costing us unneeded bandwidth at the main site.  The ultimate solution may end up being a set of IAPs at the remote site, and the controller AP being set as a local controller to our existing master.  But the solution you give may be a great stopgap measure in the mean time.  Thanks for everyone's help!