In a nutshell: It is a two-step process – creating redirection rules and configure Security Group to Service Profile bindings. Read on to learn the details.
During one of our NSX Livefire delivery an attendee mentioned that he faced problem with traffic redirection (network introspection) when configuration was done within the “Partner security services” tab. We had a discussion about the issue he encountered and the outcome gave me the idea for this blog entry, to demystify the Network Introspection configuration.
Most of the times we use NSX Service Composer to create Network Introspection. When configuring the redirection policy we have to define 3 specific parameters:
- Action: redirect to service or not;
- Service Name;
- Service Profile.
At this point if we check what was created at the “Partner security services” UI, we will see the policy rule in disabled state.
To activate the policy we have to apply it to a Security Group (SG). When applying policy to a SG, NSX will trigger 3 actions (not specified exactly in order):
- Policy Security Group (PSG) object from the Service Composer policy definition gets substituted with the SG and the rule gets activated.
- The Network Introspection, Service Profile gets applied on the SG, which also triggers filter creation.
- NSX Manager sends an API call to the 3rd party, providing the SG information. The SG shared with the 3rd party is the one defined as a source and/or destination in the redirection rule.
We can verify that the Service Profile was applied on the SG by navigating to the correct Service Definition Instance and checking the Applied Objects.
There are certain scenarios (a nice topic for future blog), in which we would like to use “Partner security services” UI for Network Introspection configuration. When we configure network introspection from the “Partner security services” UI, the Service Profile that is defined in the Action field is not bound automatically to the Security Groups, which is defined as a source or destination in the rule. It this case the binding between the SG and the Service Profile has to be done manually.
This can be accomplished by selecting the “Profile name hyperlink” in the Action column of the rule, or by editing the Service Profile “Applied Objects” at the Service Definition Instance.
It is worth mentioning that in this case the SG bound to the Service Profile could be different from the SG defined as a source and/or destination in the redirection rule. This comes in handy if we want to share Universal Security Groups (USG) information with the 3rd party provider. Of course, in this case the global (site local) SG, which is bound to the Service Profile, must include the same VMs as members for which we do traffic redirection.
The above configuration (Service Composer or “Partner security services” tab) will create a filter for each vNIC, belonging to a VM that is part of the SG, and used for traffic redirection. The filter, with the specified redirection rules, will be attached to slot 4-12 of the Service Chaining mechanism.
Using ESXi CLI we can verify the correctly applied redirection fitter and ruleset.
The “punt” keyword at the end of each rule tells us that the traffic matched by the rule will be redirected.
As we can see Network Introspection, using the “Partner security services” tab, provides configuration flexibility and expanded use case scenarios. When using this method for traffic redirection, Service Profile binding to the SG has to be configured manually. If we face problems, important verification step would be to check that the filter was created and applied to the VM vNIC with the “punt” keyword at the end of the rules.