Importing Policies Overview
CSO supports importing policy configurations from next-generation firewall devices. You can discover existing policy configuration while onboarding next-generation firewall device (without enabling ZTP) or import policy configurations from Firewall and NAT policy pages (after ZTP).. For more information about overview and configuration of ZTP on SRX Series Firewalls, see Zero Touch Provisioning on SRX Series Devices.
To import policy configuration after ZTP , see Importing Firewall Policies, and Importing NAT Policies.
To discover existing policy configuration while onboarding next-generation firewall device (without enabling ZTP), see Add a Standalone Next-Generation Firewall Site.
CSO uses object name as the unique identifier for an object (such as addresses, services, schedulers, SSL profiles, Content Security , and Layer 7 applications). During policy import, all objects that are supported by CSO are imported and all objects names are compared between what is in CSO and what is on the next generation firewall device. A conflict occurs when the name of the object to be imported matches an existing object, but the value of the object does not match. The object conflict resolution (OCR) operation is triggered to resolve the object name conflicts.
If the object name does not exist in CSO, the object is added to CSO.
If the object name exists in CSO with the same content, the existing object in CSO is used.
If the object name exists in CSO with different content, the object conflict resolution operation is triggered, providing users with the following conflict resolution options:
Rename object
This is the default option.
By default, "_1" is added to the object name, or users can specify a new unique name.
Deploying the policy will delete the original object and add the object with the new name.
There is no functional change to the firewall policy (labels only).
Overwrite with imported value
The object in CSO is replaced with the object from the import operation.
The change will be reflected for all other devices that use this object after the policy deployment.
There is no functional change to the firewall policy.
There may be possible traffic impact to all other devices that use this object the next time the other device is updated from CSO.
Keep existing object
The object name in CSO is used instead of what is on the next generation firewall device.
Policy deployment for the imported firewall policy will show the modification.
There may be possible traffic impact to this firewall because the content is different in some way.
The following section provides an example for importing policies. Here we use Address as an object type and see how to resolve the object name conflicts.
The existing objects in CSO are listed inTable 1.
Object Name |
Existing Value |
---|---|
Address1 |
198.51.100.10 |
Address2 |
198.51.100.20 |
Address3 |
198.51.100.30 |
The existing objects in the next generation firewall device are listed inTable 2.
Object Name |
Existing Value |
---|---|
Address1 |
203.0.113.10/32 |
Address2 |
203.0.113.20/32 |
Address3 |
203.0.113.30/32 |
During policy import, OCR is triggered and the object conflicts between next generation firewall device and CSO. The resolution that we have chosen is listed in Table 3.
Object Name in CSO |
Object Type in CSO |
Existing Value in CSO |
Imported Value to CSO |
Conflict Resolution |
New Object Name in CSO |
---|---|---|---|---|---|
Address1 |
Address |
198.51.100.10 |
203.0.113.10 |
Keep Existing Object |
Address1_1 |
Address2 |
Address |
198.51.100.20 |
203.0.113.20 |
Overwrite with Imported value |
Address2_1 |
Address3 |
Address |
198.51.100.30 |
203.0.113.30 |
Rename Object |
Address3_1 |
The object values and the result after resolving conflicts are listed in Table 4.
Discovered Object Name in CSO |
Discovered Value in CSO |
Result |
---|---|---|
Address1 |
198.51.100.10 |
No change |
Address2 |
203.0.113.20 |
Content changed |
Address3 |
198.51.100.30 |
No change |
Address3_1 |
203.0.113.30 |
Address3_1 created |