Wireless Access

Reply

Upgrading to AOS 6.4 - controller no longer accessible?

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?

Pasquale Monardo | Senior Network Solutions Consultant
ACDX #420 | ACMP
[If you found my post helpful, please give kudos!]
Guru Elite

Re: Upgrading to AOS 6.4 - controller no longer accessible?

What is between your controller and your host?

 



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Re: Upgrading to AOS 6.4 - controller no longer accessible?

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.
Pasquale Monardo | Senior Network Solutions Consultant
ACDX #420 | ACMP
[If you found my post helpful, please give kudos!]
Guru Elite

Re: Upgrading to AOS 6.4 - controller no longer accessible?

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.


Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Re: Upgrading to AOS 6.4 - controller no longer accessible?

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
Pasquale Monardo | Senior Network Solutions Consultant
ACDX #420 | ACMP
[If you found my post helpful, please give kudos!]
Guru Elite

Re: Upgrading to AOS 6.4 - controller no longer accessible?

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?


Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Re: Upgrading to AOS 6.4 - controller no longer accessible?

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...
Pasquale Monardo | Senior Network Solutions Consultant
ACDX #420 | ACMP
[If you found my post helpful, please give kudos!]

Re: Upgrading to AOS 6.4 - controller no longer accessible?

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??

 

 

Pasquale Monardo | Senior Network Solutions Consultant
ACDX #420 | ACMP
[If you found my post helpful, please give kudos!]
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: