Wireless Access

last person joined: 23 hours ago 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

Upgrading to AOS 6.4 - controller no longer accessible?

This thread has been viewed 0 times
  • 1.  Upgrading to AOS 6.4 - controller no longer accessible?

    Posted Feb 17, 2014 12:56 PM

    For the life of me, I can't figure out why.

     

    Going from 6.3.1.1 to 6.4.0.0 and I can no longer ping my controller or access it.

    I know the upgrade is succesful because I have console access and the AP attached to it (RAP) is broadcasting but I can no longer access it via the webui or SSH.

     

    I revert back to 6.3.1.1 and I can access my controller again.

    This is a lab controller on a private network in my lab that I access over an internal IP..

     

    i've compared run-configs and the only main difference is 6.4 adds some crypto information.

     

    Reading through RN and UG and can't seem to find anything that point to this issue.

     

    Does anyone know something I don't?



  • 2.  RE: Upgrading to AOS 6.4 - controller no longer accessible?

    EMPLOYEE
    Posted Feb 17, 2014 01:03 PM

    What is between your controller and your host?

     



  • 3.  RE: Upgrading to AOS 6.4 - controller no longer accessible?

    Posted Feb 17, 2014 01:05 PM
    firewall managed by our systems team.

    that's what I am trying to wrap my head around, I can access it without issues on 6.3.1.1 but not 6.4.


  • 4.  RE: Upgrading to AOS 6.4 - controller no longer accessible?

    EMPLOYEE
    Posted Feb 17, 2014 01:07 PM
    I would use show datapath session table <IP address of your station> when you try to connect to see if ssh is even making it there.


  • 5.  RE: Upgrading to AOS 6.4 - controller no longer accessible?

    Posted Feb 17, 2014 01:11 PM
    No sync. hmmm

    172.30.59.145 172.30.39.20 6 22 55155 0/0 0 0 1 1/3 19 0 0 Y
    172.30.59.145 172.30.39.20 6 22 55156 0/0 0 0 0 1/3 1 0 0 Y

    172.30.39.20 172.30.59.145 6 55155 22 0/0 0 0 1 1/3 19 0 0 YC
    172.30.39.20 172.30.59.145 6 55156 22 0/0 0 0 0 1/3 1 1 52 YC


  • 6.  RE: Upgrading to AOS 6.4 - controller no longer accessible?

    EMPLOYEE
    Posted Feb 17, 2014 01:15 PM
    Any ACLs on your controller ports, at all? Is there anything on that side of the firewall you can use to SSH into it with?


  • 7.  RE: Upgrading to AOS 6.4 - controller no longer accessible?

    Posted Feb 17, 2014 02:40 PM
    I'd have to get my systems team to look at that side of the firewall.

    I can access it no problem on the same subnet from a windows machine.
    No ACLs on the ports.

    I was more concerned if 6.4 enables options that are possibly not documented...


  • 8.  RE: Upgrading to AOS 6.4 - controller no longer accessible?
    Best Answer

    Posted Jun 10, 2014 02:30 PM

    I got to the bottom of this. I had 'prohibit arp spoofing' -> firewall prohibit-arp-spoofing enabled. I'll explain.

     

    Because this is in a lab my gateway is 172.30.59.1 which is the uplink that was provided to me that interfaces with the lab's pfSense firewall. When running 6.3, I don't have any issues. When upgrading to 6.4, this AOS firewall rule causes a problem where I lose access to my controller.

    With that firewall rule enabled, I was not able to ping my gateway and it would not show up in 'show arp' on the controller.

    Removing that firewall rule, I was then able to ping the IP from another station and the arp entry showed up on the controller.

     

    It seems as though because the 172.30.59.1 interface is assigned to a "generated" MAC address (when creating new interfaces on pfSense, it assigns a random MAC address), the arp spoofing does not allow the controller to create an ARP entry for my gateway.

     

    Removing the firewall rule and rebooting the controller seems to make it work.

     

    EDIT: the MAC's generated were part of RFC 7042 and are designated as unicast because they started with 00:00:5E:00:00:00 to 00:00:5E:FF:FF:FF

     

    EDIT: it seems as though the address assigned was part of VRRP??