Wireless Access

I used the WLAN wizard to create a new guest network.

I configured it to use a Captive Portal with no authentication.

I have the PFENG license in use.

I have a VLAN IP for this guest subnet.

I have two controllers (Master, Master-Standby).

This guest VLAN is making use of VRRP. So the IP scheme is, as an example, 10.0.100.2/24 (on the primary controller), 10.0.100.3/24 (on the secondary), then both configured to share 10.0.100.1/24 via VRRP.

Master controller IP, as an example, is 10.0.1.2. Master-standby is 10.0.1.3. And VRRP for this management VLAN is 10.0.1.4.

The ip cp-redirect page is 10.0.1.4.

When I connect to this guest SSID with a Captive Portal profile, I get an IP address. The scope is using 8.8.8.8 and 8.8.4.4 for DNS servers.

If I try to go to a webpage, it times out. If I try to use nslookup, it times out. If I do http://1.1.1.1 it'll load the Captive Portal page, then redirect and time out.

I've deleted and recreated this SSID multiple times to no avail.

What am I missing at this point? Why is DNS timing out? All of the local policies in use via the WLAN wizard allow FULL icmp, dns, dhcp, etc. DHCP seems to work, but DNS will not.

Hi,

1. Are you able to ping the DNS server IP from the client?
2. Check the output of "# show rights <User-role-of-client>"
3. Check the output of "# show datapath session table <DNS-Server-IP> | include <Client-IP>"

This should help I guess.

Thanks,
Rajaguru Vincent

Hi Rajaguru,

Thanks for the reply - I'll have to get another device for testing to see those commands.

For now:

1. Are you able to ping the DNS server IP from the client? NO (to be fair, I can't ping the DHCP server either, but my client still gets an IP...)
2. Check the output of "# show rights <User-role-of-client>" IN PROGRESS
3. Check the output of "# show datapath session table <DNS-Server-IP> | include <Client-IP>" IN PROGRESS

Thanks again - I'll be replying shortly,

Josh

Hi,

If ICMP is not blocked in your network, do a tracert to the DNS server IP and check where is it getting dropped. Without DNS, captive portal may not work.

Thanks,
Rajaguru Vincent 

It is not blocked. When I do a traceroute, it stops at the first hop (Aruba mobility controller).

Here's the datapath session info:

10.11.104.12    8.8.8.8         17   51670 53     0/0     0    0   1   tunnel 190  1c   3          216        FCI
8.8.8.8         10.11.104.12    17   53    60931  0/0     0    0   0   tunnel 190  8    3          216        FI
10.11.104.12    8.8.8.8         17   63541 53     0/0     0    0   0   tunnel 190  8    3          216        FCI
10.11.104.12    8.8.8.8         17   58586 53     0/0     0    0   1   tunnel 190  17   3          186        FCI
8.8.8.8         10.11.104.12    17   53    62790  0/0     0    0   1   tunnel 190  18   3          201        FI
8.8.8.8         10.11.104.12    17   53    53885  0/0     0    0   0   tunnel 190  5    2          130        FI
8.8.8.8         10.11.104.12    17   53    50152  0/0     0    0   0   tunnel 190  0    1          139        FI
8.8.8.8         10.11.104.12    17   53    55066  0/0     0    0   1   tunnel 190  1c   3          795        FI
10.11.104.12    8.8.8.8         17   57429 53     0/0     0    0   0   tunnel 190  10   3          186        FCI
10.11.104.12    8.8.8.8         17   53885 53     0/0     0    0   0   tunnel 190  5    2          130        FCI
10.11.104.12    8.8.8.8         17   59358 53     0/0     0    0   1   tunnel 190  15   3          204        FCI
8.8.8.8         10.11.104.12    17   53    63541  0/0     0    0   0   tunnel 190  8    3          216        FI
8.8.8.8         10.11.104.12    17   53    54267  0/0     0    0   0   tunnel 190  2    1          72         FI
10.11.104.12    8.8.8.8         17   56470 53     0/0     0    0   1   tunnel 190  18   3          210        FCI
10.11.104.12    8.8.8.8         17   64921 53     0/0     0    0   0   tunnel 190  b    3          210        FCI
10.11.104.12    8.8.8.8         17   55066 53     0/0     0    0   1   tunnel 190  1c   3          195        FCI
8.8.8.8         10.11.104.12    17   53    56470  0/0     0    0   1   tunnel 190  18   3          417        FI
8.8.8.8         10.11.104.12    17   53    51670  0/0     0    0   1   tunnel 190  1c   3          216        FI
10.11.104.12    8.8.8.8         17   61136 53     0/0     0    0   1   tunnel 190  d    3          201        FCI
10.11.104.12    8.8.8.8         17   50174 53     0/0     0    0   0   tunnel 190  7    3          201        FCI
8.8.8.8         10.11.104.12    17   53    61136  0/0     0    0   1   tunnel 190  d    3          870        FI
10.11.104.12    8.8.8.8         17   50152 53     0/0     0    0   0   tunnel 190  0    1          70         FCI
8.8.8.8         10.11.104.12    17   53    59358  0/0     0    0   1   tunnel 190  15   3          204        FI
8.8.8.8         10.11.104.12    17   53    60997  0/0     0    0   0   tunnel 190  0    1          65         FI
8.8.8.8         10.11.104.12    17   53    58586  0/0     0    0   1   tunnel 190  17   3          321        FI
8.8.8.8         10.11.104.12    17   53    50174  0/0     0    0   0   tunnel 190  7    3          201        FI
10.11.104.12    8.8.8.8         17   60931 53     0/0     0    0   0   tunnel 190  8    3          216        FCI
10.11.104.12    8.8.8.8         17   54267 53     0/0     0    0   0   tunnel 190  2    1          72         FCI
8.8.8.8         10.11.104.12    17   53    64921  0/0     0    0   1   tunnel 190  b    3          417        FI
10.11.104.12    8.8.8.8         17   62158 53     0/0     0    0   1   tunnel 190  5    2          134        FCI
10.11.104.12    8.8.8.8         17   62790 53     0/0     0    0   1   tunnel 190  18   3          201        FCI
8.8.8.8         10.11.104.12    17   53    57429  0/0     0    0   1   tunnel 190  10   3          321        FI
10.11.104.12    8.8.8.8         17   60997 53     0/0     0    0   0   tunnel 190  0    1          65         FCI
8.8.8.8         10.11.104.12    17   53    62158  0/0     0    0   0   tunnel 190  5    2          134        FI

It's stopping at the first hop, which is the VLAN IP of the subnet on the controller (10.0.100.2).

Hi, 

It could be because of ACLs. Check "# show rights <User-role-of-client>" and review the ACLs mapped to the user-role. 

Thanks, 

Rajaguru Vincent 

I don't think so. :/ Seems to be a mobility bug or something.

I created a brand new SSID, super basic config. VLAN, VLAN IP, DHCP, allow-all ACL, etc. The client joins, grabs an IP, then dies immediately, even with an ACL allowing everything out.

Now, when I ssh into the controller and do a ping and a traceroute from that source interface, it works just fine.

For kicks, here's the ACL the client has and it's privs:

Valid = 'Yes'
CleanedUp = 'No'
Derived Role = 'allow-all'
 Up BW:No Limit   Down BW:No Limit
 L2TP Pool = default-l2tp-pool
 PPTP Pool = default-pptp-pool
 Number of users referencing it = 2
 Periodic reauthentication: Disabled
 DPI Classification: Enabled
 Youtube education: Disabled
 Web Content Classification: Enabled
 ACL Number = 70/0
 Max Sessions = 65535

 Check CP Profile for Accounting = TRUE

Application Exception List
--------------------------
Name  Type
----  ----

Application BW-Contract List
----------------------------
Name  Type  BW Contract  Id  Direction
----  ----  -----------  --  ---------

access-list List
----------------
Position  Name                  Type     Location
--------  ----                  ----     --------
1         global-sacl           session
2         apprf-allow-all-sacl  session
3         allowall              session

global-sacl
-----------
Priority  Source  Destination  Service  Application  Action  TimeRange  Log  Expired  Queue  TOS  8021P  Blacklist  Mirror  DisScan  ClassifyMedia  IPv4/6  Contract
--------  ------  -----------  -------  -----------  ------  ---------  ---  -------  -----  ---  -----  ---------  ------  -------  -------------  ------  --------
apprf-allow-all-sacl
--------------------
Priority  Source  Destination  Service  Application  Action  TimeRange  Log  Expired  Queue  TOS  8021P  Blacklist  Mirror  DisScan  ClassifyMedia  IPv4/6  Contract
--------  ------  -----------  -------  -----------  ------  ---------  ---  -------  -----  ---  -----  ---------  ------  -------  -------------  ------  --------
allowall
--------
Priority  Source  Destination  Service  Application  Action  TimeRange  Log  Expired  Queue  TOS  8021P  Blacklist  Mirror  DisScan  ClassifyMedia  IPv4/6  Contract
--------  ------  -----------  -------  -----------  ------  ---------  ---  -------  -----  ---  -----  ---------  ------  -------  -------------  ------  --------
1         any     any          any                   permit                           Low                                                           4
2         any     any          any-v6                permit                           Low                                                           6

Expired Policies (due to time constraints) = 0

After much troubleshooting, I decided to open a case. The controller is behaving very oddly.

It had a kernel panic this morning and rebooted. Even after, nothing new works. I created another new SSID. Internal. allow-all policy. Wide open. The host will grab an IP, ping the gateway, but do nothing else, even with everything defined as allow all any, etc. Gateway can't ping hosts, but hosts can ping gateway. The whole situation is just very bizarre, since I've done all this kind of configuration many times before on many other controller pairs without issue.

Thanks for the help anyway.

Hi, 

If there is kernel panic and other issues, it is really a valid reason to open a TAC case. Please keep us posted with the feedback. 

Thanks, 

Rajaguru Vincent 

So, this is a 7205 controller and it shipped with 6.4.3.1. I was told by my SE that 6.4.3.5 should be the minimum ArubaOS for 72XX series. I updated the code, but no joy.

I spent 2 hours on the phone with Aruba TAC yesterday and they couldn't figure it out. The fundamental issue stems from the layer 3 interface ON the Aruba mobility controller. It will not pass traffic. For some reason, it'll allow DHCP out to get an IP for the host, but after that, no ICMP, no DNS, no HTTP(S), etc. Even when we apply an allow-all policy, nothing works.

The second I move that layer 3 interface from the mobility controller down to our core router, boom....everything works perfectly.

Very frustrating and confusing. I'm sure we're just missing something stupid or simple, but I don't know.

Any insight/suggestions would be appreciated.

When the default gateway of the guest network is on the controller, do you have a route from your internal network pointing to your controller for that guest subnet?

I have a route on the core router to the mobility controller VRRP IP.

So from outside the controller, I can ping the VRRP gateway of the guestnetwork and the VLAN interface of the guestnetwork, but I can't ping the hosts. Hosts can ping their gateway (L2), but can't ping beyond.

Furthermore, sshed into the controller, I can ping as the source of the guestnetwork (default gateway) and VLAN interface out no problem. So it's literally the hosts within the subnet - the host traffic will not traverse the default gateway.

Quite frankly, you should simplify and only use a single controller first.  Get rid of all the VRRPs, etc and only supply services on a single controller.  It will make it easier to see what the issue is when you do.

I agree, and that's why I did that. I created an entirely new VLAN, interface, no captive portal, no VRRP, no authentication, nothing - wide open, allow all, the simplest of configs possible - still failed.

---

@josh.bailey wrote:

I agree, and that's why I did that. I created an entirely new VLAN, interface, no captive portal, no VRRP, no authentication, nothing - wide open, allow all, the simplest of configs possible - still failed.

---

What does "failed" mean?  Can you ping the controller's ip address on the guest VLAN from your network?

Type "show port status" and make sure that none of your ports are untrusted.

Failed means no traffic passes beyond the controller. The host gets an IP, and that's it. Nothing else happens.

I can ping the guest network gateway, VLAN interface, AND the controller management VLAN IP and VRRP IP. But nothing beyond.

Unless I move the guest network gateway OFF the controller, routing doesn't seem to work. The only uplink/trunk port on the controller is trusted and passing traffic for all VLANs. But in this case, the VLAN is contained on the controller.

What is providing DHCP for the guest clients?

Do you have "ip nat inside" on the guest VLAN?

No nat enabled.

The DHCP server is on an external (to the controller) subnet. The helper addresses are on the VLAN interface of the guest network. That's the only routed service that seems to work, since the hosts will get an IP. But I can't ping that DHCP server or do anything else.

I'm researching the easiest way to do packet capturing on the controller now. It'd be nice to capture packets on the egress port of the controller (uplink to core router) to see what's coming out, and what's not.

You should:

- point the route at the physical interface of the controller with the access points (not the VRRP)

I will try that now, be right back.

Assuming this works, what happens in a failover scenario when that "physical" IP (which is really just the VLAN interface IP of the management subnet, so logical) is changed? A second route to the secondary controller IP with a higher cost?

Honestly, you need to get anything working on a basic level before discussing redundancy.  If you cannot even ping, you need to rip everything unnecessary out until you can.  A working solution should drive your redundancy discussion, after the solution works.

Agreed - that's what I've been trying to do.

So, tried your suggestion and same behavior.

- Host gets an IP from controller in this case

- Host can ping it's own gateway

- Host can ping any other interface on the controller outside of it's subnet/VLAN

- Host cannot ping beyond controller

- Wired hosts on network can ping this guest interface, but not hosts

The question is - outside of ACLs and routing, what would prevent a host from passing traffic or routing beyond the controller? Is it a controller setting? Is it a controller failure, like the controller somehow sees that host as "unauthenticated" similar to untrusted? Is there a command to check that?

Question:

Do you have any other WLAN setup on this controller that is working?

Unrelated to WLAN but when a host cannot ping past its gateway, the subnet mask is typically incorrect, either on the ip addresses the clients are getting, or the mask on the controller's interface.

Subnet seems to be fine. I made it even more simple by putting the DHCP scope/server on the controller for this test VLAN.

The two other SSIDs in use are a corporate/internal and guest - but both have their gateways elsewhere, NOT on the controller.

So, no current SSIDs working with their gateways on the controller.

Is there a way looking through the session database or some other user commands to get more info on the host status itself? I see it trying to ping out to IPs that timeout:

10.11.249.21    10.11.2.1       1    432   2048   0/0     0    0   1   tunnel 224  8    1          60         FSCI

But I don't have much ability to discern what that's telling me.

Do you have a diagram how this is all setup?  If you are even considering doing redundancy, your default gateway should not be the controller to eliminate state issues on failover.  Most people that do make the controller the default gateway just do ip nat inside and nat all of the client traffic out.  If you are making the guest VLAN a fully routable network, you might as well just do ip nat inside at the controller interface level:

config t

interface vlan <whatever the guest's vlan is>

ip nat inside

I just found based on those datapath session flags that inside nat was configured for the test VLAN I was using. I assume the TAC engineer did that, because I did not. Anyway, I removed it, but no change in behavior - now the flag is just gone from the session info.

If not the controller gateway, then what should be used? It looks like ip nat inside didn't work in this case anyway.

Right now, since I can get everything to work fine with the gateways on the core routers, I'm just going to move forward with that configuration. I've spent 4 days on this already and numerous hours with my SE, TAC, and now you. :)

I appreciate the help, but the work is piling up and I need to move on from this. Maybe some day I'll figure out what the issue was.

If you want redundancy, the layer 3 interface on your layer 3 switch on the guest vlan should be used.  That way, no matter what controller is up, the default gateway will be consistent.  You can also have your helper address on that same wired interface to provide DHCP.  You also avoid putting static routes to controller(s) for that subnet, because as long as your infrastructure advertises connected routes, you should be good.  You would need a trunk that connects each controller to your infrastructure, with each controller having an ip address on that guest subnet.  When you are ready for your guest portal, the ip cp-redirect-address on each controller would be the ip address of that controller on the guest subnet.  You would not need a vrrp on the guest subnet on each controller, because clients will use the default gateway provided by your wired network.

Secondly, if you are using the controllers ip address as the default gateway of the guest clients, the way to configure redundancy is different than that of how you would do it if only the router was the default gateway.  Try to configure and work with a single controller first, without a VRRP and then take it from there.

---

@cjoseph wrote:

Secondly, if you are using the controllers ip address as the default gateway of the guest clients, the way to configure redundancy is different than that of how you would do it if only the router was the default gateway.  Try to configure and work with a single controller first, without a VRRP and then take it from there.

 

---

I'm not. There's a management VLAN the controller IP is a part of. That is used for centralized licensing, failover, etc. But that VLAN default gateway (on the core routers) is the default gateway for the entire mobility controller. Meaning, when the guest subnet on the controller wants to route out, the host goes to it's gateway, that gateway checks the routing table and passes it on to the management VLAN out to the core routers. This routing is shown by my ability to ping/traceroute from wired hosts on the edge to the guest network interfaces.