- CheckMates
- :
- Products
- :
- CloudMates Products
- :
- Cloud Network Security
- :
- Discussion
- :
- Adding more gateways to Gateways Enforcing Data Ce...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Adding more gateways to Gateways Enforcing Data Center Objects List
Hello Checkmates,
In our DC we have a VSX cluster with 95 VS running on it, we also deployed an on-prem Cloudguard that should filter the ACI traffic
At the moment 19 gateways enforce the Datacenter Objects when running the command "cpstat vsec"
vSEC Controller Status: on
Number of disconnected Data Centers: 0
Number of Data Centers: 2
Number of imported Data Center objects: 461
Number of gateways enforcing Data Center objects: 19
Also, in the " CloudGuard Controller Service Manager Menu" (vsec_controller_cli) there are only 85 VS gateways out of 95 listed
We are using Datacenter Object for all the tenants and i don't know how i can enforce the datacenter objects on more VS or what is the issue that the Datacenter Objects are enforced on only 19 GW.
The 2nd topic would be, how can I add all 95 or more gateways to the " CloudGuard Controller Service Manager Menu" list
I have opened a TAC case for this issue but there is no real progress with it, only trial-and-error solutions.
Thank you for your support
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Updating the thread that we did remote session, found the root cause to be wrong configuration of the mgmt interface on the VSX, fixed it and now the issue is solved.
Thank you @Daniel_Ionut_Ba for the remote session.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What we did:
Followup on cpm.elg during policy installation and understand that /etc/fw/tmp/getVsData.sh script invocation on the vsx failed.
So we ssh the vsx gw and run it manually with bash debug:
bash -x /etc/fw/tmp/getVsData.sh
and saw that the script fails to get the mgmt interface.
That made us realize that the mgmt interface was incorrect.
Customer fixed it using clish APIs.
Once the mgmt interface on the vsx was correct, an install-policy fixed the CloudGuard Controller side.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are you using the datacenter object in a rule on the relevant gateway/VS?
What version/JHF is the management and gateways?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As @PhoneBoy mentioned, CloudGuard Controller only propagates identities/data center object to gateways which enforce security policy rules that contains data center objects.
So the most obvious reason for the behavior you are describing is that the security policy rules that contain data center objects are not related to those gateways.
If you can share the SR number, we might be able to provide more specific answers.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @avivs
Yes, I agree with you, but in this case what you describe does not apply.
I have as an usecase a VS, we are using the datacenter object in the policy, in the datcenert object some EPGs are imported but still this VS is not listed in the gateways enforcing Data Center objects list (cpsta vsec) neither in CloudGuard Controller Service Manager Menu (vsec_controller_cli)
the SR is
SR#6-0003792393
Thank you for your support
Daniel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @PhoneBoy
We are using the datacenter object in all the policies for all the VSX VS (for all our clients)
The output of the command vsec_controler_cli shows 87 objects but the output of cpstat vsec shows that only 19 GW enforcing Data Center objects.
vSEC Controller Status: on
Number of disconnected Data Centers: 0
Number of Data Centers: 2
Number of imported Data Center objects: 462
Number of gateways enforcing Data Center objects: 19
on the SMS we are running R81.10 Take110
On the VSX GW R80.30 Take236
Thank you for your support
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Daniel_Ionut_Ba please share with me the file $FWDIR/conf/vsec_controller_targets_data.set from your mgmt server.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Gil_Sudai, Could you please send me a private message where I can replay and send the file?
Thanks,
Daniel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Updating the thread that we did remote session, found the root cause to be wrong configuration of the mgmt interface on the VSX, fixed it and now the issue is solved.
Thank you @Daniel_Ionut_Ba for the remote session.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Gil_Sudai thank you for your fast response and support, you guys are the best!
One small request, could you please add to this post the script for verifying the management interface and a small description, unfortunately, i have closed the ssh connection and forgot to save it? Maybe someone else might have the same issue and this can save a lot of time
Again, many tanks for your help!
Cheers!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What we did:
Followup on cpm.elg during policy installation and understand that /etc/fw/tmp/getVsData.sh script invocation on the vsx failed.
So we ssh the vsx gw and run it manually with bash debug:
bash -x /etc/fw/tmp/getVsData.sh
and saw that the script fails to get the mgmt interface.
That made us realize that the mgmt interface was incorrect.
Customer fixed it using clish APIs.
Once the mgmt interface on the vsx was correct, an install-policy fixed the CloudGuard Controller side.