Wireless Access

 View Only

  • 1.  Captive portal redirect issues, Aruba 7220 controllers

    Posted Jan 21, 2026 12:50 PM

    We have 2 Aruba 7220 controllers setup in VRRP. Access points are a mix of 635s, 535s, 534s, 325s, and 324s. Users connecting reach a pre auth role and are forwarded to a captive portal for self registration. Once they register, they are authenticated via MAB on clearpass and then the controller puts them in the authenticated role which allows access out to the internet.

    About 1-2 months ago, we upgraded from 8.10.0.17 FIPS to 8.10.0.19 FIPS. After the upgrade, we have found that some users are unable to authenticate because they are not getting redirected to the captive portal. Couldn't pinpoint it to any type of device or OS, just random. Everything from iphones, androids, mac books, surface pros, and other devices. Can't even pinpoint it to a specific AP or location. Just completely random. At the same time this is happening, there are anywhere from 600-1200 active wifi users with zero issues, to include other devices that are new users and are hitting the captive portal successfully. The non working devices are connected to the AP, but it says "Connected, no internet". Looking in the controller, these devices are usually stuck in the pre-auth role that SHOULD be forwarding it to clearpass.

    I opened up a TAC case and we worked through a lot of troubleshooting. Everything looks good with configuration from TAC's point of view. Did some packet captures and after looking at the pcap, we concluded that the devices unable to reach the captive portal are not reaching it because they cannot resolve the FQDN, so DNS problem. Dug into it a little further and from the controllers point of view, the devices doesnt have an IP address. User table it only showing a mac address.

    This is where it gets kind of weird. The device itself has an IP, but the controller isnt seeing it. Our core switch, which sits higher in the stack above the controllers, does see the IP in the ARP table. The DHCP server, hosted on a hyperv VM, usually sees the mac address in the DHCP pool. But for some reason, the controllers in the middle of all this do not see the IP and therefore cannot forward the client to clearpass.

    Here are some things we have done to fix the issues on clients, but this is also not consistent. Some of these work one time then won't work the next time.....

    • Some devices just start working on their own after some time
    • Remove the MAC from the DHCP server and have it pull another IP ( some of these MACs were showing as expired, some had brand new leases)
    • Assign a static IP to the client (doesn't forward the device to clearpass, but does give it access to the internet)
    • Turn on MAC randomization on the client. With a new mac, it will connect. Turn mac randomization back off and connection fails again]

    Last week we had zero issues. Went 5 days with no user complaints. At this point, we thought maybe the problem worked itself out. Then just yesterday, we have a few more pop up with the same issues.

    Does anyone have any idea if anything on the controllers could be causing this? Something that would only allow certain MACs to get a DHCP address and other not? Should we upgrade again? Is this just a client/dhcp server issue?

    This VLAN that the wireless clients use is also used by wired devices. The wired devices don't hit the controller and authenticate through Cisco ISE instead of clearpass. We have zero issues with these devices getting an IP address. This leads me to believe that something is wrong on the controller side, but like I said, we just can't seem to pinpoint anything. And it's weird that one of the temp fixes we found was to delete it from the DHCP server hosted in a VM on hyper-v.

    Topology:

    Client >AP> PoE cisco switch > Cisco Distro switch> Controllers

    Controllers > Same Cisco Distro switch as above > Cisco Core switch> Cisco Datacenter switches > Servers with HyperV hosting DHCP/DNS



    -------------------------------------------


  • 2.  RE: Captive portal redirect issues, Aruba 7220 controllers

    Posted Jan 21, 2026 02:21 PM

    FYI, generally we'd really rather not see you commingle wired and wireless users in the same VLAN when those wired users aren't coming through the controllers.

    Are you working with TAC for the missing IP addresses on clients?



    ------------------------------
    Carson Hulcher, ACEX#110
    ------------------------------



  • 3.  RE: Captive portal redirect issues, Aruba 7220 controllers

    Posted Jan 21, 2026 04:34 PM

    Yeah its something we are working on changing. Originally the wired part of the vlan was only for printers, but others have jumped on it with their wired devices.

    TAC pointed out its a DHCP problem, but doesn't think its related to the controller since we are not doing DHCP on the controller. We do DHCP on a hyper-v server. We had a TAC case open for about a month, but I closed it last week because we went about 5 days without any reports of more problems. The engineer we worked with looked everything over and was at the point that we were just going to do more packet captures to see if we could uncover any more information. 

    I'm just looking to see if anyone else out there has any ideas what could cause something like this,  because we are kind of lost right now. Like is there some kind of DHCP snooping like you have on Cisco switches that would block certain DHCP packets? Or something that would block a specific mac for a certain time? 

    My only other idea is to upgrade up to 8.10.0.20 or 21 since we did not see this issue until we upgraded. Hoping maybe its a bug in the software.

    -------------------------------------------

    Original Message


  • 4.  RE: Captive portal redirect issues, Aruba 7220 controllers

    Posted Jan 21, 2026 04:52 PM

    The controller is always snooping the DHCP in order to populate the user table and datapath information with the correct mapping, but there is zero action that should ever be blocking any one client from the DHCP process unless you've applied an ACL to their user role that is blocking that specific traffic.

    DHCP isn't a requirement unless you have marked the option for DHCP enforcement i.e., enforce dhcp.

    Upgrading to the latest is always a good option, or even downgrading to the version you feel was working well in order to validate that such was the case.

    About the only thing that could be done for troubleshooting is to do the captures to see where the process is breaking down, to make sure that the DHCP packet is always being sent out by the server and being presented to the controller.



    ------------------------------
    Carson Hulcher, ACEX#110
    ------------------------------

    Original Message


  • 5.  RE: Captive portal redirect issues, Aruba 7220 controllers

    Posted Jan 21, 2026 09:41 PM

    Ok I guess thats what I was asking. Is there any reason or any possible way a controller could be blocking dhcp packets, other than an ACL?

    -------------------------------------------

    Original Message


  • 6.  RE: Captive portal redirect issues, Aruba 7220 controllers

    Posted Jan 21, 2026 09:50 PM
    Edited by chulcher Jan 21, 2026 09:53 PM

    There shouldn't be, no. That's why the packet capture is important for troubleshooting this, you have to validate that the discover is leaving and that the offer is reaching the controller.  Or if you can validate that the issue is specifically tied to a software version, then you have something else to look at or give to TAC.

    We have had bugs that matched this description in the past, we've also had customers report similar behavior and be able to narrow the issue down to a specific client chipset and driver version.



    ------------------------------
    Carson Hulcher, ACEX#110
    ------------------------------

    Original Message


  • 7.  RE: Captive portal redirect issues, Aruba 7220 controllers

    Posted Jan 21, 2026 10:47 PM

    Thanks. Appreciate the response. We will dig deeper into the packet captures and see what we can find out. 

    -------------------------------------------

    Original Message


Related Content