SMB cluster passive node GAIA access

[IZoom]

Hello mates,

I have cluster from SMB. The GAIA access is working only to the active node. I am confused from that - even I have enabled

set admin-access interfaces ANY access allow

I am not able to access passive node directly. Only one way is to access SMB over SSH from active node. Do exist there workaround how to access passive node (in best case) via HTTPS://<passive_node_IP>:4434

Cluster has dedicated sync interface, managed is from smart-1 cloud.

Thx for any advice.

[IZoom]

in FW logs I can see only traffic dropped with message information: Address spoofing. I am not able to find a root cause why spoofing is detected or debug that. 

[_Val_]

Versions and models in use, locally or centrally managed?

[IZoom]

I believe it's a generic problem, whatever I am running 2x 1800 (80.20.30) in cluster managed by Smart-1 cloud.

[_Val_]

It is not a general issue. You should be able to access both members via their private IP addresses with both WebUI and SSH, if you are not doing it via VPN connection.

Mind, Standby member has very limited menu with WebUI.

If this is not your case, please open a TAC case. 

[IZoom]

well. I have only VPN access right now. I am sure during onsite install I had the same issue. As soon I added interface to cluster and assign virtual IP -> I lost access to passive node. The active node is available from cluster IP and node IP.

I need to access the GAIA only due to creating/updating new VLANs and in some cases to update DCHP settings.

[_Val_]

Huh, that explains it. Move WebUI out of the VPN. It will not work through the tunnel.

[IZoom]

Out of VPN when access GAIA from WAN is enabled, I can reach both nodes. To be honest, I am not comfortable with allowed access to GAIA from WAN.

From inside the network (not VPN) I cannot reach passive node on any interface 

[G_W_Albrecht]

Use HTTPS://<passive_node_IP>:4434 - set in Device > System > Administrator Access !

[IZoom]

Yeah, This is configured well, whatever there is no option to set specific interface, where the service listen. Actually this is solved by firewall rule. The issue is that no client device is on management LAN, therefore all traffic has to be routed (without routing it's working well).

sk106425 -> seems there is only way to disable antispoofing on management interface.

[G_W_Albrecht]

I assume you in reality rather do run Embedded GAiA 😎 For an SMB cluster you have to finish First Time Configuration Wizard on both devices first - that had been possible ? You did follow Quantum Spark 1500, 1600 and 1800 Appliance Series R80.20.30 Centrally Managed Administration Guide p.18ff ? Then you should have three IP addresses:

- local WAN IP of Node 1 (active)

- local WAN IP of Node 2 (standby)

- virtual Cluster IP

When High Availability is enabled on the WAN interface, then the cluster requires an additional unique virtual IP address. This virtual IP address is visible to the network and ensures that cluster failover events are transparent to all hosts on the network.

If you want access to the cluster, you get to the active node, but both nodes also are available using their local IP. As you do change all settings on active node only, as the standby will sync the changes automatically, you usually only use the virtual cluster IP !

[IZoom]

Hello. Thank you for advise.

I was not aware of special documentation "R80.20.30 Centrally Managed Administration Guide". I have red the basic documentation and Smart-1 cloud documentation, nowhere was mentioned anything like that. Everywhere was just mentioned that in management cluster object needs to be pre-created with dummy GW first. The conversion of standalone GW to cluster is not supported.

In my case all nodes has own IP on each interface and own virtual IP for each clustered interface. (included WAN - Public IP) + dedicated sync interface (set under topology)

As you do change all settings on active node only, as the standby will sync the changes automatically, you usually only use the virtual cluster IP !

I suppose this is not true for the OS basics such a DHCP, don't you?