NSX-T move security policy after V2T migration

This blog is part of a series about optimalisations that can be done after the Distributed Firewall has been migrated from NSX-V to NSX-T. Most of the optimisations are based on the DFW only migration option. Please have a look at that blog to see the steps that were used for the V2T migration.

One of the optimisations is to move or copy a Security Policy from one category in NSX-T to another. Since there is no option in the NSX-T management GUI to move a Security Policy between categories, I had a look at the options using the NSX-T API. The complete list of NSX-T API calls can be found at code.vmware.com.

For this blog I want to copy or move the QUARANTINE policy from the Application category to the Emergency category. And as a precaution, please test this in a lab environment before using this method in a Production environment.

Retrieve the Security Policy

The first step is to retrieve the complete list of Security Policies to find the ID of the Security Policy we wish to copy or move. This can be done with the following API call:

GET https://<NSX Manager ip>/policy/api/v1/infra/domains/default/security-policies

In the output of this API call the ID for the Security Policy can be found. In this example I’m using Postman.

The next step is to retrieve the settings for the specific policy, this can be done with the following API call:

GET https://<NSX Manager>/policy/api/v1/infra/domains/default/security-policies/<Policy ID>

For this use-case the API call will look like:

GET https://<NSX Manager>/policy/api/v1/infra/domains/default/security-policies/16c71b04-15ce-4882-b7bc-cf08f8ec901c

The output or response form this API call will detail the Security Policy including all the firewall rules in the Security Policy. The part that we want to change is the category setting, this can be found at the bottom of the output.

Move the Security Policy

My first try was to simply change the category from Application into Emergency and use the PATCH option to push the information back into NSX-T. The result of this PATCH API call gives a hint why a GUI option to move the Security Policy isn’t available.

So, if a Security policy can’t be moved from one category to another, the next option is to copy the Security Policy to another category and (optionally) delete the Security Policy in the original category.

Copy the Security Policy

Because the complete information for the Security Policy can be retrieved with an API call, we can use that same information to create a new JSON to copy the Security Policy. The structure of the JSON file for the Security Policy looks like this:

{
    "rules": [
        {
                                             <Information about the Firewall rule 1>
        },
        {
                                             <Information about the Firewall rule 2>
        },
        {
                                             <Information about the Firewall rule 3>
        }
    ],
               <Information about the Security policy>
}

To be able to use the JSON file to create a new Security Policy I removed all the unique information from the JSON file. For each firewall rule entry, I removed the:

• "id"
• "path"
• "relative_path"
• "parent_path"
• "unique_id"
• "rule_id"
• All the information starting with an underscore, like "_create_user" and "_create_time"

Make sure that if you remove the last entry "_revision" to also remove the comma behind "is_default". Otherwise, the JSON file will no longer be valid.

For the Security Policy I removed the same entries, except for rule_id. For some of the entries I wasn’t sure if they needed to be removed, like

• "sequence_number"
• "internal_sequence_number"

But the PUT API call at least works with these entries in the JSON file and they are changed by NSX-T on creation of the Security Policy. Then I changed the category from Application to Emergency.

Because all the references to the Security Groups and Services are already in the JSON file, we do not need to change anything there.

Creating the Security Policy

The next step is to put the information back into NSX-T. This can be done using the same API call, but this time with the PUT method:

GET https://<NSX Manager>/policy/api/v1/infra/domains/default/security-policies/QUARANTINE

The last part of the API call will become the ID for the Security Policy in NSX-T. This value needs to be unique in NSX-T.

If all went well the result of the API call should be Status 200 OK and the Security Policy is available in the Emergency category.

My next step will be to create a script for this, but that will be fuel for another post.