Issues getting a Checkpoint R80 config to load into the Migration tool.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Issues getting a Checkpoint R80 config to load into the Migration tool.

L1 Bithead

The customer is using SmartCenter (not ProviderOne) and it appears that smartcenter uses some sort of quasi-global object repository that doesn’t export everything when you run the suggested export command in the Migration Tool (Expedition version). PSC's observed that only a subset of the object repository is exported into the config file.

 

Any Help please?  Are we missing something?

1 accepted solution

Accepted Solutions

L1 Bithead

I think we close this issue. The last single files you sent me this morning as per my request worked, Expedition took them, load the configuration without issues. I got it loaded and all consistent.

 

- I have done a quick review and it looks clean

- Daniel please review it, I think now you can actually start your migration clean-up process with this.

- You got all objects, object-groups as we should, all the Security Rules and NATs as well as the extra clone created by the tool.

- You got 4 objects “1.1.1.1” that are used, this is normal as they might belong to a Domain type object on Checkpoint, you need to find the value of this object with the customer and replace the 1.1.1.1.

 

So, what was the issue?

 

  1. As per my findings, the customer was pulling the configuration from the console (CLI) with wrong parameters. Customer was pulling the right Security Rule set from the right Firewall/gateway but was pulling the NAT rules set from another firewall gateway.

The result of this of course were inconstancies on the loaded configuration to expedition, lots of missing groups, objects, NATs etc.

This usually happens when we use Copy and paste and rush without seen the exact details of the command.

  1. The second problem I need to Share with Albert.

- We did follow the process lay on the guide to migrate R80. The breaking down of the “.jason” as per limits 400 for security rules-set and 500 for NAT rules-set did not work on Expedition.

- I had to ask the customer to create a single “.jason” file for security rules-set and a single file for NAT rules-set.

- Expedition took it and load it fine.

 

That is all I have on this, please let me know if any comments.

I will update the Blog Paul created with the solution found. Thank you.

 

 

Regards,

---------------- Alex LLabres 


 

View solution in original post

5 REPLIES 5

L7 Applicator

The problem was in the Checkpoint side Paul? 🙂

L1 Bithead

I think we close this issue. The last single files you sent me this morning as per my request worked, Expedition took them, load the configuration without issues. I got it loaded and all consistent.

 

- I have done a quick review and it looks clean

- Daniel please review it, I think now you can actually start your migration clean-up process with this.

- You got all objects, object-groups as we should, all the Security Rules and NATs as well as the extra clone created by the tool.

- You got 4 objects “1.1.1.1” that are used, this is normal as they might belong to a Domain type object on Checkpoint, you need to find the value of this object with the customer and replace the 1.1.1.1.

 

So, what was the issue?

 

  1. As per my findings, the customer was pulling the configuration from the console (CLI) with wrong parameters. Customer was pulling the right Security Rule set from the right Firewall/gateway but was pulling the NAT rules set from another firewall gateway.

The result of this of course were inconstancies on the loaded configuration to expedition, lots of missing groups, objects, NATs etc.

This usually happens when we use Copy and paste and rush without seen the exact details of the command.

  1. The second problem I need to Share with Albert.

- We did follow the process lay on the guide to migrate R80. The breaking down of the “.jason” as per limits 400 for security rules-set and 500 for NAT rules-set did not work on Expedition.

- I had to ask the customer to create a single “.jason” file for security rules-set and a single file for NAT rules-set.

- Expedition took it and load it fine.

 

That is all I have on this, please let me know if any comments.

I will update the Blog Paul created with the solution found. Thank you.

 

 

Regards,

---------------- Alex LLabres 


 

where you checking the zip file didnt have any folder inside? It must be zipped with

 

zip rules.zip *

In that folder should be all the .json files plus a file called "order" within it the list in order of the json files like

 

rules_0_400.json
rules_401_650.json

If you used MacOS probably will create a folder inside an invalide the zip file for Expedition

 

Remember to do it from cli to ensure no folder is created inside the ZIP.

L0 Member

There where 2 issues on this case:
-----------------------------------------

1) The issue initially was pulling the information from the correct Checkpoint Security Gateway/Firewall BUT by mistake they where pulling the NAT coonfiguration from the wrong Source (Diffrerent Firewall) using the guide command below:

The correct Security rules firewall set is : "Internet Security"

mgmt_cli show access-rulebase offset 0 limit 400 name "Internet Security" details-level "full" use-object-dictionary true --format json > RuleSet_0_400.json
mgmt_cli show access-rulebase offset 401 limit 400 name "Internet Security" details-level "full" use-object-dictionary true --format json > RuleSet_401_800.json
mgmt_cli show access-rulebase offset 801 limit 400 name "Internet Security" details-level "full" use-object-dictionary true --format json > RuleSet_801_1200.json

 

giving the files :
RuleSet_0_400.json
RuleSet_401_800.json
RuleSet_801_1200.json

we ZIP them into -> RuleSet_Security.zip

 

The NATs where pulled from the wrong Firewall
mgmt_cli show nat-rulebase offset 0 limit 500 package "Bill_Fw" details-level "full" use-object-dictionary true --format json > NATRuleSet_0_500.json
mgmt_cli show nat-rulebase offset 501 limit 500 package "Bill_Fw" details-level "full" use-object-dictionary true --format json > NATRuleSet_501_1000.json
mgmt_cli show nat-rulebase offset 1001 limit 500 package "Bill_Fw" details-level "full" use-object-dictionary true --format json > NATRuleSet_1001_1500.json

 

giving files:
NATRuleSet_0_500.json
NATRuleSet_501_1000.json
NATRuleSet_1001_1500.json

We zip the files into -> NATRuleSet.zip

 

The correct NAT rules set firewall set is : "Internet NAT" they used "Bill_FW" the load nto the migration tool Expedition of course was wrong and with inconcistancies.


2) the sexonf issue was that Expedition was not taking the ZIP files correctly. It was loading all the .json files from the Security ZIP File but only loading the NAT first file and ignoring the other 3 files on the .zip.

 

The solution:
----------------

to load all the R80 configuration in this particular case:


- Asked the customer to run the command for the entire configuration as per example below:

 

mgmt_cli show access-rulebase offset 0 limit 1000 name "Internet Security" details-level "full" use-object-dictionary true --format json > RuleSet_0_100.json

 

giving 1 security jason File:
RuleSet_0_1000.json

 

And

 

mgmt_cli show nat-rulebase offset 0 limit 1500 package "Internet NAT" details-level "full" use-object-dictionary true --format json > NATRuleSet_0_1500.json

 

giving 1 NAT Jason file:
NATRuleSet_0_1500.json

 

Then, the Expedition load was clean and ready to work on the migration tool.

Regards,
Alex
-

Where is the "order" file?

  • 1 accepted solution
  • 11641 Views
  • 5 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!