SmartMove disable layers in policy?

[Denis_Gozdzik]

I am currently migrating Juniper ISG to Checkpoint gateway using SmartMove. This tool is great, but I have one problem: we need to use a flat policy structure, not a layer, which is generated from SmartMove.

Is it possible to somehow disable layers when policy will be under domain or tweak a bash script to create a flat structure?

thanks,

[Jerry]

did you followed precisely sk115416 with it?

[Denis_Gozdzik]

Yes, I followed sk115416 and migrated policy is layered.

[Jerry]

I'm not 100% what happened but you must have placed your configuration into the:

Get the Juniper configuration file from the gateway. See vendor documentation for "show configuration" commands.

• From Junos: get the configuration file in XML format
• From ScreenOS: get the configuration file in CLI format. 

should you've done CLI format there is literally no way it may go onto the Layered Network policy. There must have been something wrong on the way Denis.

is there any chance you can move your layered-network policy to the flat one? on Dashboard you should be able to "migrate" your Layered one onto the "Policies" where you can see only "Access Control" and "Threat Prevention" blocks.

please paste here how your Layered Policy looks like (mark up your specific datails) - there must be a way of making this right even though you've migrated the ScreenOS via SmartMove.

did you managed to import XLM file with "Convert NAT configuration" or without ?

I've done JunOS in the past from my beloved SRX's and it all went perfectly fine, ISG/SSH are quite vintage once hence my question is "what went wrong" ?

[Denis_Gozdzik]

This is how the policy looks like.

etc, I have about 400 rules divided into layers.

This is part of the bash script:

mgmt_cli SmartMove_Create_Policy -s id.txt > /dev/null 2>&1
echo 'create package [--_policy]'
cmd='mgmt_cli add package name "--_policy" threat-prevention "false"  ignore-warnings true -s id.txt --user-agent mgmt_cli_smartmove'
run_command
echo 'Layers: Creating 9 sub-policies'
echo 'create layer [---dmz_sub_policy]'
cmd='mgmt_cli add access-layer name "---dmz_sub_policy" add-default-rule "false"  ignore-warnings true -s id.txt --user-agent mgmt_cli_smartmove'
run_command
echo 'Add rules to layer ---dmz_sub_policy'
cmd='mgmt_cli add access-rule layer "---dmz_sub_policy" comments "Intra Zone Blocking Enabled" action "drop" track-settings.type "Log" position "top" name "Sub-Policy Cleanup rule"  ignore-warnings true -s id.txt --user-agent mgmt_cli_smartmove'
run_command
echo -n $'\rrule 1/3 '
cmd='mgmt_cli add access-rule layer "---dmz_sub_policy" source "any" destination "any" service "any" action "drop" track-settings.type "Log" position "top" name "Rule685"  ignore-warnings true -s id.txt --user-agent mgmt_cli_smartmove'
run_command
echo -n $'\rrule 2/3 '
cmd='mgmt_cli add access-rule layer "---dmz_sub_policy" source.0 "---dmz" source.1 "EDS-RUN-_---dmz" source.2 "---dmz" destination.0 "--" destination.1 "--" service.0 "http" service.1 "https" action "accept" track-settings.type "Log" position "top" name "Rule556"  ignore-warnings true -s id.txt --user-agent mgmt_cli_smartmove'
run_command

You can clearly see that it creates layered policy.

I did a get config output from Juniper ISG, so I have a CLI view.

I did use following settings, I have no NAT configuration in ISG config:

I have a workaround: I can migrate ISG policy to Juniper SRX format, then I can use xml file to migrate to Checkpoint, but please tell me if there is anything I can tweak here.

thanks

[Jerry]

Yes. Now I can tell you that this is abnormal to create from TXT file  (CLI option) multi-layered import.

If I were you I would have ask Tomer Sole‌ or Dameon Welch Abernathy‌ as in my opinion (and I've done only XML version from JunOS myself) there is something wrong with the SmartMove that it imports TXT file onto the GAIA as "Layered" one.

I see now that you're correct. This is something what R&D should be made aware of as I'm not gonna be helpful here I'm afraid. Sorry Denis. Let's see what our GURU's says

Cheers

Jerry

[Tomer_Sole]

If the source vendor uses a zone-based policy, we convert it to zone-based inline layers. So that's how a single text file is converted to a tree of policies - because this reduces the need to write "source zone" and "destination zone" in each one of the rules.

Does this make sense?

[Jerry]

totally. that makes perfect sense Tomer, but while every zone-based 3rd party vendors these days produces a config. file like Denis's Juniper ISG/SSH mentioned, would that mean that it is going to be like that every time and creates multi-layered CP set?

does it mean it is an expected behavior from SmartMove or it depends? you know what I mean, would that be for every configuration which is zone-based these days?

I'm asking as when I made my SRX also zone-based migration it was flat-layer via SmartMove and I definitely did not have multi-layered outcome in R80.10. I've done this nearly a year ago in my lab and it went smooth as if it was native upgrade_export/import

[Robert_Decker · Accepted solution]

SmartMove tool uses layered policy approach, by design, for every vendor.

If you need Juniper SRX policy to be migrated as a flat policy, define it as global in Juniper SRX. There is no other way.

Robert.

[Jerry]

that is exactly what I meant Robert  my JunOS config. display-set was flat (global) hence my conversion to GAIA was smooth and none-layered. Seems Denis's isn't that simple plus it isn't JunOS but ScreenOS based - that's what this topic is all about. JunOS - we all know it is simply easier to handle - ScreenOS - not so much.

[Denis_Gozdzik]

Thanks, this is something I looked for.

I will define my ISG policy as global.

[Herold]

Is there also a workaround for a Cisco ASA config conversion to be flat policy? I did my Cisco to Checkpoint conversion successfully, but we don't want to keep the Layered Policy. Is there any way i can get a flat Checkpoint Policy?

Thanks.

[Robert_Decker]

The same goes for Cisco ASA - make the access groups global ("global") instead of inbound ("in").

In addition, disable the inter/intra security traffic ("same-security-traffic") to block creation of trafic between zones, in case you do not want to create rules for traffic between them.

Robert.

[Jerry]

btw. what is the verions of your pre-import ScreenOS?

Have you seen the limitations to ScreenOS version 6.3 (R19B/R22) and above ?

Just thoguht it is wise to mention as this seem important prereqs.

[Denis_Gozdzik]

It's R21. But I see no difference in the config which I need to migrate between R21 and R22.