VSX: SCP backup being blocked by non-existing rule 705 ???

[Ruud]

I am trying to setup a scheduled backup on some vFW's running on our VSX cluster which should be sent to a linux based backup server. I use the same configuration on a few hardware FGT's which works fine.

I use the following config rule for this :

            add backup-scheduled name "Daily" scp ip x.x.x.x  path /home/username/firewall-name/ username "xxxxxxxx" password xxxxxxxx

When entering this command on one of the vFWs on the VSX cluster, it tries to connect but fails and doesn't save the backup configuration. I checked the firewall logging to see what went wrong. This traffic is coming from the mgmt interface and is being being blocked by a rule number 705 ??

Our last rule is rule 620, 705 doesn't exist.  I checked the connection details and clicked on the rule 705. This redirects me to rule 620 which is a drop Any Any Any rule.

We have rules in place to allow this traffic, which work just fine for our other firewalls. Those rules aren't hit for the backups from the vFW's. I have tried pinging the backup server from the vFW, which gives the same result: Blocked by rule 705 ?

I suspect that the rules that work for the other firewalls aren't hit because of the fact that the mgmt interface of the vFWs are not in the firewall zones being used to allow this traffic but can't change the zone of the mgmt interfaces. I also vaguely remember something about routing mgmt traffic from the vsx nodes and/or vFW's through a vFW on that cluster is not possible ?

[Vincent_Bacher]

I might be wrong here, but this looks a bit like the way VSX treats traffic that’s generated by a VS itself.

One idea to consider might be to trigger the backup from the VSX level (VS0). 

[Bob_Zimmerman]

There's no point scheduling a backup (or even running a backup) in VSs other than 0. The whole VSX cluster is one OS, one filesystem. It all gets backed up together, and there is no way to restore a backup of just one VS.

That said, yes, the traffic is probably going out from the VS's real IPs (which are automatically selected) rather than the cluster VIP (the IP you specify in the VS object's topology).

[Chris_Atkinson]

Which version and JHF is the environment, is the invalid rule ID in the log card or somewhere else?

[Ruud]

We are using 2 6900 VSX nodes, using R81.20 Take 89

[Chris_Atkinson]

Something like this might be relevant: sk180449: Wrong layer number in SmartView log  

The source interface will follow the routing which of course will be limited in the context of VS0.

[the_rock]

What rule number is it showing under matched rules?

[Ruud]

705, which is non existent

[the_rock]

Thats odd...have you tried running fw up_execute to see what it shows?

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_CLI_ReferenceGuide/Topics-CLIG/FWG...

[Bob_Zimmerman]

What is the number of your cleanup rule in the policy? Some versions combine the rule numbers of layers in an odd way, turning 25.680 into 705, for example. This is really common with MDSs.

[_Val_]

Is this, by any chance, an MDS management? If the answer is yes, do you use Geo-policy? If not that, a multi-layered policy?

[_Val_]

Also, is your clean-up rule set to log or not?