NO SE in Exclude List
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
|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||demonsxt2-ServiceEngines|
|4||Service||<prefix>-ControllerCluster||Service Object: Contains protocols/ports for the Controller. Allows TCP ports 22, 8842 and UDP 123||demonsxt2-ControllerCluster|
On Creating the Virtual Service
|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
|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.
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.
|*2*||Group||<prefix>-ServiceEngineMgmtIPs||The ServiceEngineMgmtIPs group is updated||demonsxt2-ServiceEngineMgmtIPs|
|*3*||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. :
|7||Group||<prefix>-<VS Name>||Contains the DataNIC IPs of the SE||demonsxt2-demovs|
|8||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
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,
Navigate to Inventory > Groups. You can see that there are five groups created prefix
demonsxt2(the Object Name Prefix):
Click on View Members to identify the Virtual Machines/ IP Addresses.
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,
Navigate to Security > Distributed Firewall.
Ensure that the connectivity strategy is selected as Whitelist.
Click an existing section or rule.
Click on Add Rule.
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.
Click on Publish.
For detailed 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.
Note: DFW objects will not be deleted if they are referred in DFW rules. On deleting the rules, all stale objects will be cleaned up.
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:
The categorization of the rules under different DFW policies is the choice of the end user. The following model was adopted:
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
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>-
Allow Backend <prefix>-<VS Name> web group <prefix>-<Pool Name> web-group<prefix>-
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.
- During VS Scale-in and Scale-out some of the long-standing connections could be dropped.
|December 22, 2020||Published the content for No SE in Exclude List (Version 20.1.3|