unable to create VSX Cluster

[an_technical]

Hi Team, 

Good day. I am trying to add VSX cluster to our existing SMS. We see cluster creation is done but when VSX cluster policy is being pushed it fails with attached error screenshot:

I see below following prompt when I login into VSX gateway CLI:
{Expert@GW-1:0]

But when I do vsx stat I get following output - vsx is not supported on this platform

VSX Cluster Policy is installed on vsx gateway when I do fw stat. I refer sk98244. Accept SmartUpdate connections is already checked in global properties.

Can you guide where can be the issue. Traffic is allowed between SMS and VSX gateway for all ports.

I also wanted to tell we have one more VSX cluster gateway configured on same SMS and we have edited implied_rules.def to send traffic for checkpoint ports over VPN not through implied rules. The security policy is created using VPN community.

I took tcp dump on gateway and I see only syn traffic is coming from SMS to VSX gateway on port 18191 and 18192 but VSX gateway is not replying with (syn,ack)

[the_rock]

Can you run fw stat -b AMW from ssh and see what it says?

18191 error is typical SIC error issue that tells you connectivity with mgmt is broken.

my lab:

[Expert@VSNEXT-s01-01:0]# netstat -na | grep 18191
tcp 0 0 0.0.0.0:18191 0.0.0.0:* LISTEN
[Expert@VSNEXT-s01-01:0]# fw stat -b AMW
Anti Bot: Disabled (network signatures=0 behavioral=0)
Anti Virus: Disabled (network signatures=0 behavioral=0)
IPS: Enabled (use "ips stat")
Threat Emulation: Disabled
Threat Extraction: Disabled
Mail policy: Off
Zero Phishing: Off
files: http=0 ftp=0 smb=0 smtp=0 pop3=0
more: fileapp_ctx_enabled=0 ifi=0 http_dynamic_enabled=0 icap_server_enabled=0 min_severity=2 min_confidence=0
Policy: R82-lab-policy Wed Apr 30 13:30:34 2025 (traditional=1)
[Expert@VSNEXT-s01-01:0]#

[the_rock]

To add, also run zdebug to see why this is droppiung. Hopefully it shows us something.

Andy

[Wolfgang]

@an_technical you have changed the default behavior, sending management between SMS and gateways via VPN. Maybe the connections to your new VSX from SMS tries to go the same way and they are reaching the new VSX. Something wrong with the VPN?

In general I recommend to not sending traffic between SMS and gateways via VPN. If something goes wrong with your tunnel (configuration, expired certificates, time issues etc.) you can‘t configure the gateway. Maybe there are requirements for you but I would not recommend such configuration.

[an_technical]

Hi @Wolfgang : The new VSX gateway and SMS is not over VPN but in same DC. I can see syn packet is coming to gateway. Even if it thinking to send it to VPN which don't exist. We should see a (syn,ack) back but not silently dropping the connection. 

[the_rock]

What do you see if you run tcpdump or fw monitor?

Andy

[an_technical]

In tcpdump we see syn only coming from SMS to VSX gateway on 18191 and 18192 but for 257 (logs) we see communication happening b/w SMS and VSX gateway. In zdebug + drop , I don't see any drop. 
I can run fw monitor today.

[the_rock]

From your screenshot, appears communication failing because its not connecting for SIC, port 18191. I did not see anything for port 257, plus, that would not be needed for policy to succeed.

Andy

[an_technical]

When I add VSX gateway while creating VSX cluster, we need to give SIC password so SMS can communicate to VSX gateway and after doing that trust is established. This all happens when I click finish button and VSX cluster policy is pushed.

How in start is shows communicating and failed during policy installation.

[the_rock]

K, so if thats the case, then I would try this. As a test, leave policy as any any allow, and try install that. If it fails, policy is NOT your problem, so I would check routing.

Andy

[emmap]

You saw you get a " vsx is not supported on this platform" error - what platform is this on? What version? How did you build it?

[an_technical]

FW model: 26000

Version: R81.20

Hotfix: Take 98

Adding VSX cluster from the smart console and then following steps.

[emmap]

So it was a fresh install on 26K, you did the first time wizard to configure it as a cluster XL cluster member (and not a management instance) and then installed the JHF? 

It seems like something in the policy that you are installing is cutting off the comms to the management server once it's installed. Unlikely to be anti-spoofing, and it should be installing a new policy package that it helpfully created for you in the cluster creation wizard. When it popped up the policy options, did you change the cleanup rule to 'accept any/any'? If you have changed implied rules and whatnot that would at least rule out the policy as being an issue.

[an_technical]

Hi @emmap : Yes fresh clean install to R81.20, selected cluster_XL in high availability. Installed hotfix 98

I was trying to change last rule from drop to allow but it don't give me option to change there. I can only change source object.

[the_rock]

Are you sure you are looking at the right rule? If its default network policy, you can absolutely edit all the values.

Andy

[an_technical]

Hi @the_rock : I am taking about this one in attached screenshot.

The cluster creation fails. if I cancel or just click on X. It will remove all configuration.

I found in zdebug drop, 18192 is dropped by no policy match. So we removed implied rules configuration and that's why it need a rule to allow the communication and there is no option to allow any/any during VSX cluster creation as its has pre-defined rules.

The users should get option to change it there as we get option for source object.

[emmap]

You may just need to temporarily enabled all the 'Allow Control Connections' implied rules while you create the cluster. 

VSNext doesn't have this issue as we don't use that VSX cluster creation wizard anymore.

[AkosBakos]

Hi @an_technical 

Are the implied rules logged? How old the MGMT, or is this a new installation too?

Akos