Importing Stonesoft Configurations Results in Empty Security Policies
Stonesoft exported_data.xml files have the capability to define, in one single config file, multiple configurations for multiple devices.
From what we have learnt so far, there are cases in which the configuration XML defines the mapping between different security policies and devices. Recently we have found a couple of cases in which this mapping is not directly defined in the data_export.xml file, or at least I have not determined yet with certainty how this mapping is defined. We are investigating the logic that the people at Forcepoint are using to identify the mappings based on the XML.
Sometimes it is the FW device name, which matches the policy name. Other times, it is an additional granted policy mapping, and some other cases seems to have an alternative method that I am trying to find out. (the dbkey that the different elements have in the XML file does not seem to be the final answer).
In the case you would find that the Migration Tool did not manage to import the security policies for your Stonesoft exported_data.xml file, please do the following.
Step 1: Determine the name of the device you are willing to import. Look in the XML for the entries "fw_single" or "fw_cluster", such as this example below. We are interested in valued of the "name" parameter
<fw_cluster auto_reboot_timeout="10" cluster_mode="balancing" db_key="999" default_nat="true" [...] name="The-Firewall-Cluster" [...] tracking_mode="normal">
Step 2: Determine the name of the security policy that should be mapped to the selected device. Look for the entries "fw policy". Here also, w e are interested in valued of the "name" parameter
<fw_policy db_key="1111" [...] name="The-Firewall-Policy" [...] template_policy_ref="The Template" template_policy_ref_key="111">
Step 3: Modify your exported_data.xml to include a section (in blue color in the example below) that specifies the mapping between the device and the policy. Modify the bold texts to refer to the names you have found in the steps 1 and 2. Notice (1) that the added section is placed as a child of the generic_import_export tag in the XML tree. Talking plain, make sure that this section is placed just after the line <generic_import_export ...>. Notice (2) that the <list_entry value="polic_name" /> is closed with the />. Do not forget the slash char /. We suggest to copy&paste the blue section and modify it with your corresponding device and policy names. Notice (3) that you can repeat the granted_policy_ref section as many times as devices and policies you would like to map. In the example, we have included a second mapping in orange color.
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE generic_import_export SYSTEM "generic_import_export_v5.8.dtd"> <generic_import_export build="8824" update_package_version="632"> <granted_policy_ref engine_ref="The-Firewall-Cluster"> <list> <list_entry value="The-Firewall-Policy"/> </list> </granted_policy_ref> <granted_policy_ref engine_ref="Another-Firewall-Single"> <list> <list_entry value="Its-Firewall-Single-Policy"/> </list> </granted_policy_ref> [... more lines come below ...]
This mapping, clearly defines that the FW (a cluster in this case) "The-Firewall-Cluster" should load the policy with name "The-Firewall-Policy"; and that "Another-Firewall-Single" should load the policy "Its-Firewall-Single-Policy".
When we get more information in how Stonesoft determines this mapping based on original exported_data.xml, we will implement the logic so you do not need to manually include the mappings.
We wish you a great migration process,
Welcome to all the Beta Testers. Beta version for the Migration Tool 3.2 is avaiable. If you want to contribute to test the new capabilities and provide feedback just download the new version from here and update your MT.