Wireless Access

Hi all,

In Tunnel forwarding Mode, the clients get their IP addresses from the AP (DHCP in the range of 192.168.190.X/24), so if you have more than one VAP using Tunnel mode the same network will be used by the clients, my question is when the traffic is back how it will be forwarded to the correct source knowing that they may have the same IP address. Is there any NAT happening? 

Thanks

Which product are you talking about?  We do not have a product with tunnel mode where dhcp is provided by the access point.

maybe I am not understanding very well, but I see in the tunnel mode my clients are getting IPs in this range and other range, so I assumed it is a DHCP from the AP.

Which product?

Aruba Controller 7200, AP Type 225

The access points on a controller do not provide dhcp in tunnel mode.  

Ok, can you explain how the traffic between the clients and any internal or external resources is going to be in the Tunnel Mode and in the Bridge Mode?

Please see my explanation here:  https://community.arubanetworks.com/t5/Wireless-Access/Bridge-and-tunnel-Mode/m-p/547739/highlight/true#M92859

Thanks for your support, it was really helpful information. But I have the following question, in Tunnel Mode, the traffic will pass through the GRE tunnel until reaching the controller without being able to access local LAN. After the traffic reaches the controller it can be routed again and reach the LAN right? so what is the difference here between Tunnel and Bridge since both can now access the LAN (Ignore the Vlan setting). 

Also, I would like to know the traffic flow for a Tunnel Mode in the following scenario:

I have a CAP's in different locations using tunnel mode to the controller which is located in another location, the IP's are leased to all AP's through a separate DHCP server. In this setup, I see the clients are getting another IP's in the range (192.168.190.0) which is different than the AP range,  so in order for this traffic from this range to access the internet or the internal resources it should be NAT-ed in the controller for example, but I see no configuration for any NAT statement inside the controller

In tunnel mode, the client vlan is independent of the access point vlan.  Client traffic is tunneled back to the controller and then can be placed on whatever VLAN is trunked to the controller.  Alternatively, you can create a vlan that only exists on the controller and then source-nat all of that traffic out of the controller...  That is probably what you have deployed here.

ok great, how can I check if source-nat is deployed in the controller?

It is typically deployed at the ip interface level.

- Find out what vlan your client is in;  ssh into the controller and type "show user-table verbose".  Your client vlan is in the parentheses.

- Type "show vlan status" to see if nat inside is enabled.

Thanks a lot but the nat is disabled, so I think src-nat not deployed here, right ?

2020 N/A N/A N/A 1 Disabled Regular GE0/0/1 N/A Disabled

The controller does not even have an ip address on that VLAN, so it is unlikely that it is doing source nat.  Find out what device is the default gateway of clients, and that device is probably doing the source nat.  The controller is merely bridging traffic to the 2020 vlan EDIT: on Gigabitethernet 0/0/1.

Great, I will check that, thanks for your usual support. 

Dears,

Is there any way to find the IP and the subnet mask for the AP from the controller either by GUI or CLI? I tried to show ap active and show ap database I only got the IP without the subnet.

Please note that AP's are getting their IP's from a separate DHCP server in which I have no access to it right now.

Regards, 

show ap debug system-status ap-name <name of ap> | begin ifconfig

Thank you for your kind reply, however, I have another question, I need to change the master IP in all access points because I am going to change the controller IP's, can I use the same command from the current controller to change the IP's of the AP remotely? if it is possible could you please show me how I can do it. 

Note:

The AP's take their IP's from a DHCP server, and the Aruba master is configured in the DNS to resolve the IP

You should use the command:

"show ap consolidated-provision info" to reveal the ip address, subnet mask and whether or not an AP got its address via dhcp:  https://www.arubanetworks.com/techdocs/ArubaOS_86_Web_Help/Content/arubaos-solutions/1cli-commands/sh-ap-consld-prv.htm?Highlight=consolidated

You should use the command:  "ap consolidated-provision info" to print a file with information above for all of the access points connected to the controller:  https://www.arubanetworks.com/techdocs/ArubaOS_86_Web_Help/Content/arubaos-solutions/1cli-commands/ap-consol-prov.htm?Highlight=consolidated

If the AP is now statically configured with a master ip address, you will have to remove that ip address for discovery to work properly.

What version of ArubaOS are you using?

You can provision the APs and set the ip address to dhcp, so that the static ip address is removed.

My version is Version 6.5.4.6

*************************

Below is the example of the "show ap consolidated-provision info ap-name"

ipv4 address type: dynamic
ipv4 address: 10.x.x.x
ipv4 netmask: 255.255.255.128
ipv4 gateway: 10.x.x.x
ipv4 lease: 69xxx
ipv4 dhcp server: 10.x.x.x
ipv4 dns server: 10.x.x.x, 10..x.x.x
ipv6 address: none
master: 10.x.x.x
master discover type: ADP
previous lms: 10.x.x.x
lms addrs [0]: 10.x.x.x
lms addrs [1]: 10.x.x.x

The discovery type is ADP is this mean that the master IP is not statically assigned and once I change the Aruba-master entry in the DNS to be the new IP the AP will automatically discover it?

Correct!

one last thing, does the ADP will work even if the AP's were in different locations/subnets because I have many locations each of it has its own subnet and the controller is also having its own subnet?

Here is the priority:

1- If you have the masterip set statically in the AP, the AP will attempt to contact the controller with that ip address

2- If the controller is on the same subnet as the AP, when the AP sends a broadcast and the controller responds, the AP will attempt to connect to the controller

3- If your DHCP scope has dhcp options 43 and 60 set correctly, the AP will attempt to go to the ip address of the controller with those options

4 - Whatever your dhcp domain is set to, the AP will attempt to contact the controller at "aruba-master.<your dhcp domain>"

For example, if the masterip is not set in the AP, the controller is not on the same subnet as the AP and you do not have dhcp options 43 and 60 set, the AP will attempt to resolve aruba-master.dhcp domain.com and try to connect to the controller at that ip address:

https://www.arubanetworks.com/techdocs/ArubaOS_6_5_4_X_Web_Help/Web_Help_Index.htm#ArubaFrameStyles/AP_Config/AP_Discovery_Logic.htm?Highlight=discovery

Perfect, this means that I am good now :), thank a lot for your usual and prompt support.

Hi,

   after I changed the IP of the controllers I am seeing the AP's in the output of show ap database and I am able to ping them, however, the lms IP need to be change match the new IP's so I changed inside the system profile in the controller and the AP's showing that they got the new LMS IP but still I am able to see any AP in the show ap active output, what could be the problem?  Also If I want to reboot the AP remotely is there any command from the controller that allows me to send it inside the AP to reboot it or at least check the configuration inside the IP?

If the APs are being redirected to an ip address that doesn't exist, they need time to reboot and reconnect to the controller.

If the AP doesn't have contact with the controller, you cannot reboot it with a command; you have to wait until it times out, reboots and finds the controller again (a few minutes).  You can choose to remove the lms-ip entirely and that will allow the APs to "stick" to the controller that they first discover...,

Ok, but some of the AP's are provisioned manually and I need to access them to change the discovery type to DNS.

I have the IP of the AP from the DHCP would you tell what are the default username and password? 

It is not easy to do that via the commandline.  I would change all of your static APs to dynamic before changing the ip address of the controller....OR...If the controller will just have a different ip address on the same subnet, I would add a loopback on the controller as the old ip address in order to have APs that are statically configured still find the controller.  Then I would provision them to dynamic...

Hi,

I did the migration of the two controllers successfully, but I have small problems, one of them is that for some users when they connect through guest said they are not being redirected to the captive portal, and when they open the URL link for the captive portal they can connect and get authenticated, what could be the problem? 

below is my captive portal configuration :

aaa authentication captive-portal "XYZ-GUEST-cp_prof"
default-role "R_Guest"
server-group "XYZ-GUEST_srvgrp"
redirect-pause 3
no logout-popup-window
protocol-http
login-page "http://clearpass.xyz.local/guest/guest_aaa.php"
no enable-welcome-page
single-session

Hi,

On which type of devices is this happening?

You need to check your guest initial role (before authentication) and make sure no whitelist entries are there depending on your device type... For example, for Android connectivitycheck.gstatic.com is blocked ..etc..

Do you have a Layer 3 IP address on the guest user vlan on the controllers?

Hi Ayman,

the model is Aruba7210), Version 6.5.4.6

I will verify the whitelist but before the migration, all was working fine so I am assuming no whitelist issue however I will verify.

No there is no L3 interface in the controller instead, it is in the SW. 

Note:

Some users are working fine but others are not. 

You will need the controller to have a a L3 interface in the VLAN used by the clients accessing the Captive Portal. The L3 interface is to allow the controller to intercept the DNS Reply to the client and re-direct to the Captive Portal. This also means, the clients in the Guest VLAN will also need a valid and working DNS server.

Can your Guest clients perform a nslookup and resolve a URL to an IP Address?

Thanks Craig, But actually it was working before fine without this configuration and when I migrate the Controllers some of the users stopped, so is this L3 interface for users on the controller mandatory? 

It is not mandatory, but I've found it is easier to achieve. If not, you'd need to consider the following:

It is not mandatory but it is easier as such as indicated by Craig..