All the groups and service objects used for creating these Distributed Firewall (DFW) rules are auto-created by the Avi Load Balancer NSX-T cloud connector with the Object Name Prefix configured during the NSX-T cloud creation in the Avi Load Balancer Controller. Therefore, enabling the Service Engine virtual machines to be included in the DFW rules.

Note:

The DFW rules must be created manually. Only the objects required are created automatically by Avi Load Balancer Controller.

The following objects are created automatically:

During Cloud Creation

S.No

Object

Naming Convention

Description

Example

1

Group

<prefix>-ControllerCluster

Destination: Contains all the Controller Management IPs

demonsxt2-ServiceEngineMgmtIPs

2

Group

<prefix>-ServiceEngineMgmtIPs

Source: Contains all the Service Engine IPs

demonsxt2-ServiceEngineMgmtIPs

3

Group<prefix>-ServiceEngines

Contains all the Service Engines as VMs

Contains all the Service Engines as VMs

4

Service

<prefix>-ControllerCluster

Service Object: Contains protocols/ports for the Controller. Allows TCP ports 22, 8842 and UDP port 123

demonsxt2-ControllerCluster

On Creating the Virtual Service

S.No

Object

Naming Convention

Description

Example

5

Service

<prefix>-<VS Name>

All the VS ports. For example, HTTP (80), HTTPS (443) will be a part of this object

demonsxt2-demovs

When Pool is Attached to the VS

S.No

Object

Naming Convention

Description

Example

6

Service

<prefix>-<Pool Name >

Contains all the pool ports. For example, the backend servers are listening to port 80 or 8080, will be picked up from the NS Groups and populated here.

demonsxt-demovs-pool

When SE is Created During Placement

After the SE is chosen for VS placement, the following groups are updated with the information of the new SEs created.

S.No.

Object

Naming Convention

Description

7

Group

<prefix>-ServiceEngineMgmtIPs

The ServiceEngineMgmtIPs group is updated

demonsxt2-ServiceEngineMgmtIPs

8

Group

<prefix>-ServiceEngines

The ServiceEngines group is updated

demonsxt2-ServiceEngineMgmtIPs

VS Placed on the SE

When the virtual service gets placed on the SE, the following groups are created and used to generate the frontend communication:

S.No

Object

Naming Convention

Description

Example

9

Group

<prefix>-<VS Name>

Contains the DataNIC IPs of the SE

demonsxt2-demovs

10

Group

<prefix>-<VS Name>VSServiceEngines

Contains the VS Service Engine list

demonsxt2-demovs VSServiceEngines
The complete set of objects that will be created at the group level and the virtual service level are as shown below:


Viewing the Objects

You can search the objects auto-created for establishing DFW rules in the NSX-T manager.

To view the objects from the NSX-T managers:

  1. Navigate to Inventory > Groups. You can see that there are five groups created prefix demonsxt2 (the Object Name Prefix):



  2. Click View Members to identify the Virtual Machines/ IP Addresses.



Similarly, navigate to Inventory > Services to view the auto-created service objects.

Creating DFW Rules

For creating DFW rules, from the NSX-T manager:

  1. Navigate to Security > Distributed Firewall.

  2. Ensure that the connectivity strategy is selected as Whitelist.

  3. Click an existing section or rule.

  4. Click Add Rule.

  5. Configure the rule, as required, for example, SE-to-Controller communication:

    • Source is the Service Engine

    • Destination is the Controller group. (The object is <prefix>-ControllerCluster)

    • Services Allowed are the Controller services (port 22, 8443, and UDP 123) (The object is <prefix>-ControllerCluster)

    • Applied to all the Service Engine groups.



  6. Click Publish.

For step-by-step procedure for creating DFW rules and policies, see Add a Firewall Rule.

In the case of a virtual service, frontend and backend rules can be created.

Important:

Before deleting a virtual service, ensure you delete any firewall rules referencing NSX groups associated with that virtual service. If you do not delete the firewall rules, you will need to manually delete these groups. When a virtual service is deleted, the NSX cloud connector tries to delete the associated NSX groups. If any groups are still used in an NSX firewall rule, the deletion attempt will fail, leaving the groups in NSX as unlinked objects, no longer managed by the cloud connector.

After deleting the firewall rules, ensure you delete the NSX groups associated with the deleted virtual service. When creating a new virtual service, the NSX groups managed by the cloud connector are created with a unique ID derived from the virtual service UUID. If you recreate a virtual service with the same name as a previously deleted one and the old NSX groups haven't been cleaned up, new NSX groups with the same name but different unique IDs will be created. This can cause confusion when configuring firewall rules. Therefore, ensure the groups related to the deleted virtual service are cleaned up before recreating a new virtual service with the same name.

Click Edit button and create the Sources and Destinations as required.

The rule will be applied to the source and the destination for this virtual service, as shown below:



Categorizing the rules under different DFW policies is the end user's choice. The following model was adopted:

  1. DFW Policy for all Avi Load Balancer SE to Avi Load Balancer Controller communications: This policy has each rule for the different clouds (if multiple)

    Name

    Sources

    Destinations

    Services

    Profiles

    Applied To

    Action

    <cloud-name>

    <prefixname>ServiceEngines

    <prefixname>ControllerCluster

    <prefixname>ControllerCluster

    <prefixname>ServiceEngines

    Allow
    Each DFW policy for each virtual service with front-end and back-end rules in it.

    Name

    Sources

    Destinations

    Services

    Profiles

    Applied To

    Action

    Frontend

    Clients

    Group with VIP-IP

    <prefix>-<VS Name>

    client<prefix>-<VS Name>VSServiceEngines

    Allow

    Backend

    <prefix>-<VS Name>

    Web Group

    <prefix>-<Pool Name>

    web-group<prefix>-<VS Name>VSServiceEngines

    Allow
Note:

  • The model discussed above assumes the Avi Load Balancer Controller is not in the Overlay Transport Zone and does not require any DFW rules.

  • Clients and Pool server Groups(web-group) must be created separately by the end-user.

Caveat

Some of the long-standing connections could be dropped during virtual service scale-in and scale-out.