ExtremeCloud IQ behind haproxy - device update failed

[jurajama]

I have installed ExtremeCloud IQ virtual appliance (version 20.1.5.2-NGVA) in a private VMware cluster where the IQ VM does not have a public IP, but AP’s access it via haproxy-VM that has got public IP and mediates traffic to the internal IP of IQ VM. haproxy is configured to mediate ports TCP-80 and TCP-443.

I have configured AP (model AP305C) to use HTTP for connection to IQ and configured haproxy public IP as the target server via AP’s web GUI.

The initial connection works fine via TCP-80 and the AP appears in IQ. However when I try to apply policy for the AP, I see “Device update failed” error which indicates that HTTPS connection to IQs private IP via TCP-443 fails. I see the same also when tcpdumping on the router that provides internet connection for the AP, there are TCP-443 SYN packets that AP sends towards IQs private IP.

Apparently when IQ sends configuration update command to the AP, IQ puts its own IP-address inside the command and that is IQ VMs private IP-address that cannot be accessed by the APs in the internet. Instead the APs should open TCP-443 connection to the same public haproxy-IP that it used also for TCP-80 connection.

My question is the following: Is there some configuration parameter in ExtremeCloud IQ where I could tell what it should consider as its own public IP?

I think this requirement for public IP configuration isn’t anything too unique, as the same issue would be faced as well if the IQ node would be behind a floating-IP of cloud platform. Logically that would be the same as in my case when using haproxy in between the AP and IQ.

[jurajama]

@zlinuxboy I did not have any solution to that issue, so I never got the system work properly in this environment. However it was just a PoC to get familiar with the installation procedure and now I know that a real production-like environment should have a public IP interface if the APs are in the internet.

[zlinuxboy]

I think my problem is the same as this one. My xiq va(version 20.1.5.2-NGVA) was deploied as vm on a private subnet, and I config port forwading such as

tcp public-ip 80 -> private-ip 80
tcp public-ip 443 -> private-ip 443
tcp public-ip 3000 -> private-ip 3000

"https://public-ip:3000" work fine, "https://public-ip" was redirect to "https://private-ip/acct-webapp/login", have you fix your problem? @jurajama 

[SamPirok · Accepted solution]

The interface does not need to be public, it just needs to be either on the same subnet as your APs, or to have a route set up between your APs and your manager instance on your backend network. 

[jurajama]

Thanks for the confirmation.

With your comment about managing this via network DHCP/firewall, do you mean that the precondition for using XIQVA is that the interface-IP of XIQVA VM must be public so that the APs can access it directly, or alternatively there is squid type of HTTPS proxy in between that can mediate traffic between “XIQVA network” and “AP network”?

The thing is that if I want my APs be located anywhere in the public internet, then that would imply that also XIQVA VM’s interface should be directly attached to the internet, which I prefer to not do but have haproxy on front of it as an additional security layer separating the public internet and private network.