SE deployment in NSX-T with DFW

Overview

Prior to Avi Vantage version 20.1.3, as a part of the NSX-T security configuration, adding the Avi SE to the DFW exclude list was a requirement. This implies that no DFW rules were applied to any traffic coming into the SE or going out of the SE.

Starting with Avi Vantage 20.1.3, all the groups and service objects used for creating these DFW rules are auto-created by the Avi NSX-T cloud connector with the Object Name Prefix as configured during the NSX-T cloud in the Avi 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 Controller

The following objects are created automatically:

During Cloud Creation

Object Naming Convention Description Example
Group <prefix>-ControllerCluster Destination: Contains all the Controller Management IPs demonsxt2-ServiceEngineMgmtIPs
Group <prefix>-ServiceEngineMgmtIPs Source: Contains all the Service Engine IPs demonsxt2-ServiceEngineMgmtIPs
Group <prefix>-ServiceEngines Contains all the Service Engines as VMs demonsxt2-ServiceEngines
Service <prefix>-ControllerCluster Service Object: Contains protocols/ports for the Controller.
Contains TCP ports 22, 443, 8443 and UDP port 123.		 demonsxt2-ControllerCluster

On Creating the Virtual Service

Object Naming Convention Description Example
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

Object Naming Convention Description Example
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.

Object Naming Convention Description Example
Group <prefix>-ServiceEngineMgmtIPs The ServiceEngineMgmtIPs group is updated demonsxt2-ServiceEngineMgmtIPs
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. :

Object Naming Convention Description Example
Group <prefix>-<VS Name> Contains the DataNIC IPs of the SE demonsxt2-demovs
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:

Objects

Viewing the Objects

The objects auto-created for establishing DFW rules can be searched 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):

    Objects

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

    Objects

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

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 on 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 is the Controller services (port 22, 8443, and UDP 123) (The object is <prefix>-ControllerCluster)
    • Applied to all the Service Engine groups.

    Rules

  6. Click on Publish.

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

In the case of a virtual service, frontend and backend rules can be created.
Click on the 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:

Rules

The categorization of the rules under different DFW policies is the choice of the end user. The following model was adopted:

  1. DFW Policy for all Avi SE to Avi 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

  2. 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

Notes:

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

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

Caveat

  • During virtual service scale-in and scale-out some long-standing connections could be dropped.

Document Revision History

Date Change Summary
December 22, 2020 Published the content for No SE in Exclude List (Version 20.1.3)