AVI integration with NSX-T Distributed Firewall (DFW) – Part 3 – From Virtual Service into NSX-T DFW

In these parts, I will show and explain how to configure and use the AVI integration with NSX-T Data Center Distributed Firewall (DFW).

The version of NSX-T I used was 3.1.1 (due to old configurations, I use the Manager Policy for the DFW) and AVI 20.1.5.

When we say AVI Integration with NSX-T, it means that we create an “NSX-T Cloud” from AVI.

Official AVI Documentation related to this topic: https://avinetworks.com/docs/20.1/nsx-t-no-se-in-exclude-list/#creating-dfw-rules

Part 3 – From Virtual Service into NSX-T DFW

For this Part 3, I assume that the SE are working correctly and they can reach the AVI Controller.

Here we want to be able to create a new AVI Virtual Service and apply the corrects rules in our NSX-T DFW. We want to allow only the authorized traffic (open ports) from a frontend (Client) and backend (Servers) perspective.

The idea will be to have, for each new VS, two rules:
1. Allow from any client IP (that is in my case but you can be more specific) to reach the VIP only with the configured ports.
2. Allow the SEs, used to handle the VS, to reach the backend servers only on the allowed ports. These ports are the ports used by the AVI Health Monitor in order to check if the servers in the pools are UP.
For this second point, we are going to reuse the NSX-T Security Group “pool” created in Part 1 (ref Part 1 : NSX-T Security Group used as a back-end server pool).
As a reminder, with this Security Group, we are able to add/remove dynamically the backend servers through NSX-T Tag. This Security Group is used in the AVI Pool configuration as well.

A good point with this NSX-T DFW integration is that all the unwanted traffic in frontend will be drop at the vNIC SE level (DFW). Like this, the SEs (OS) will not have to drop themselves this unnecessary traffic.
For example: If we have a web Virtual Service allowing the ports 80 and 443 with HTTP-to-HTTPS Redirect enable of course 😉 Then the SEs will not allow any client on other ports. However, this not allowed traffic would reach the SEs. With the NSX-T DFW this traffic will be drop at the vNIC directly.

Ready to start ?
Like for the SEs the integration of AVI with NSX-T will create and maintain for us some useful Security Groups and Services.

In the NSX-T Services section, we will find the frontend and backend allowed ports.
If I had/removed a new port to my service (VS) or Health Monitor (Backend), these Service Groups will be directly updated.

Service Ports (frontend)
Health Monitors (backend servers)
The two dynamic and maintained Services for frontend and backend.


We also have two different dynamic Security Groups managed by AVI.
A huge point with these Security Group appear when we scale out our VS (add the VS to another SE) or scale in (remove the VS from a SE), these groups will always be updated dynamically.

The first group contain all the IPv4 and/or IPv6 on the VIP Segment.
Each SE VMs, which take care of the VS, will have one vNIC on the VIP Segment.


The second group contains the SE VMs used for this Virtual Service.
Here we have all the IPv4 and IPv6 used by the SEs (management IPs, all the VIP Segments IPs).

The SE VMs in used for this VS.


Before creating our DFW rules, we still need some other manual Security Groups:
1. The backend servers pool Group (ref Part 1 : NSX-T Security Group used as a back-end server pool). -> sg.avi-pool-itstxaas001-t
2. A frontend VS VIP Group IPv4 and/or IPv6 -> sg.avi-vip-itstxaas001-t
3. (Optional) If you want to specify the frontend client you can create a Group in my case I will allow “Any” source client IPs.
4. (Optional) A Group that contain all the other VS VIP Group of the NSX-T DFW Section -> sg.avi-all-vip-itst_xaas

NOTE: In my case, we have a NSX-T DFW Section which represent a vRA Business Group -> itst_xaas.
We can have multiple VS and VIP per Business Group. The idea with the Group number 4 is to add all the individual VS VIP group of the Business Group into it.
Doing this we just need one “deny any any” rule instead of one for each VS/VIP.

The Security Group for the backend server pool. Using the Security Tag on the backend VMs.

For the VS VIP Group, I’ve added manually the IPv4 and IPv6 used for my VS on AVI.


My last and optional Group include all the VS VIP Group of the NSX-T DFW Section representing a vRA Business Group.
For this example, I only have on VS VIP Group inside it.

We can finally create our two DFW rules.
1. Allow from any client IP to reach the VIP only with the configured ports.
2. Allow the SEs, used to handle the VS, to reach the backend servers only on the allowed ports. These ports are the ports used by the AVI Health Monitor in order to check if the servers in the pools are UP.

We need to add the VS Service Engines Group, the one that contains the SE VMs, in the “Applied To:” for this NSX-T DFW Section.

In order to find easily the logs in my Syslog (vRealize Log Insights), I’ve added a Rule Tag for each of my two rules.

Frontend rule hit and logged

Backend rule hit and logged

At this point my VS is working as wanted, however, we can add the “deny” rule at the end of the NSX-T DFW Section in order to drop all the other frontend traffic.
In my case, instead of adding a deny rule for all my VS VIP Groups, I will apply only one rule which contains all my VS VIP Groups.
We can enable the logs when needed for a Security purpose.

Above I was trying to do a Telnet and SSH on the VS VIP.
Before that I applied the deny rule, it was trying and reaching the SEs but couldn’t connect.
Obviously, it’s normal as these ports are not open on my VS.

After applying the deny “Reject” rule, we can see that the DFW at the vNIC level was doing the job.

Leave a Comment

*

code