- Products
- Learn
- Local User Groups
- Partners
-
More
Join Us for CPX 360
23-24 February 2021
Important certificate update to CloudGuard Controller, CME,
and Azure HA Security Gateways
How to Remediate Endpoint & VPN
Issues (in versions E81.10 or earlier)
IDC Spotlight -
Uplevel The SOC
Important! R80 and R80.10
End Of Support around the corner (May 2021)
Hey all,
I'm having some issues with setting the limit of the show access-rulebase API command.
I try to pull the whole rulebase (limit 500) I receive the errors below. However I did a little testing and seem to have found a "sweet spot" with the limit setting. If I request a limit of 186 or below it works fine, however if I try 187 or above it errors out. Is this a bug or is it just me? Any input would be appreciated.
-Andrew
Server Details:
Running on Vmware
Version: R80.10 take 421
Hotfix: Jumbo Take 42
Here are the errors:
Gaia CLI
FWMGMT> show access-rulebase name "Policy Security" limit 187
CLINFR0329 Invalid command:'show access-rulebase name "Niagara Security" limit 187'.
mgmt_cli tool
.\mgmt_cli.exe show access-rulebase name "Policy Security" limit 187 -s .\id.txt
code: "generic_err_invalid_parameter"
message: "Invalid parameter for [action]. The invalid value: [73eb837e-41f1-47fb-9a27-a520f00a2a65]"
SmartConsole CLI
show access-rulebase name "Policy Security" limit 187
code: "generic_err_invalid_parameter"
message: "Invalid parameter for [action]. The invalid value: [73eb837e-41f1-47fb-9a27-a520f00a2a65]"
Web Services
HTTP: https://FWMGMT/web_api/show-access-rulebase
Request: {"name":"Policy Security","limit":"186"}
error: (400) Bad Request
I continued to do some testing after my original post and have identified the root of the problem. The problem is not in the limit argument, but rather the type of rule or more specifically the action applied to the rule. I tried the "show-access-rulebase" command with a limit of 1 and an offset of 186 and this failed with the same error as before. I was not able to pull the information for rules 187 to 190, but I was fine for the remainder of the rulebase. On closer inspection I found that all 4 of these rules are the same type rule and the only rules like it in the rulebase. These rules are all legacy "Traditional Mode" VPN rules. It seems that the API command "breaks" when it tries to read them.
Here is an example of one of these "Traditional Mode" VPN rules:
All of these "Simplified Mode" VPN rules work fine with the API command:
*Note: These examples are not "proper" rules, they are just merely examples.
The API breaks on the "Client Encrypt" action.
I am sure that these rules "should" have been converted ages ago, so that is where I will start.
I hope this helps anyone else that comes across similar issues.
By chance, how much RAM does your VM have allocated to it?
At a minimum, I recommend 16gb.
It only has 8GB of RAM and rarely surpasses 75%.
That being said, I should note that all logging is being done on a separate dedicated logging server.
It turns out that my problems were around the rules themselves.
Thanks.
I continued to do some testing after my original post and have identified the root of the problem. The problem is not in the limit argument, but rather the type of rule or more specifically the action applied to the rule. I tried the "show-access-rulebase" command with a limit of 1 and an offset of 186 and this failed with the same error as before. I was not able to pull the information for rules 187 to 190, but I was fine for the remainder of the rulebase. On closer inspection I found that all 4 of these rules are the same type rule and the only rules like it in the rulebase. These rules are all legacy "Traditional Mode" VPN rules. It seems that the API command "breaks" when it tries to read them.
Here is an example of one of these "Traditional Mode" VPN rules:
All of these "Simplified Mode" VPN rules work fine with the API command:
*Note: These examples are not "proper" rules, they are just merely examples.
The API breaks on the "Client Encrypt" action.
I am sure that these rules "should" have been converted ages ago, so that is where I will start.
I hope this helps anyone else that comes across similar issues.
That's good to know, thanks for sharing.
Hi Andrew, thanks for raising this issue and investigating it on your own including sharing the analysis with the forum.
We’re already aware of this issue, and even have a fix for it which was not released in the jumbo accumulator yet.
If you would like to get this HF, please open SR or wait for the next JHF.
About CheckMates
Learn Check Point
Advanced Learning
WELCOME TO THE FUTURE OF CYBER SECURITY