Create Security Policies
This section describes ways to create security policies.
| Where Can I Use This? | What Do I Need? |
|---|
Create security policy rules that will used to auto generate steering rules used in steering
policy.
When you
Generate Steering Rules, you will have the option to generate
steering rules based on pre-rules, post-rules, or all. If you select All, the VMware
plugin for NSX creates a steering rule for each applicable security in the pre and
post-rules. This can result in the creation of unnecessary steering rules and make
managing the rules more difficult. To help easily separate your steering rules from your
security rules, you can create your steering rules as post-rules and security rules as
pre-rules.
To auto generate a steering rule-based on a security rules created on Panorama, the security rule
must meet the following criteria:
Belongs to a parent or child device group registered
with an NSX-T Service Manager.
Is an intrazone policy and includes only one zone.
Does not include a static address group, IP range, or netmask
configured for the rule.
When deciding where to define your NSX-T steering rules in Panorama—pre
or post rulesbase—consider the number of security policy rules and
NSX-T steering rules you will create on Panorama and the order in
which the rules are applied to traffic. Pre-rules are applied to
traffic before post-rules.
Pre-Rules—you can use the Panorama pre-rulebase to define
your NSX-T steering rules and VM-Series firewall
security policy rules.
If your define the security rules and steering rules in the same
rulebase, you must consider the order of the security rules relative
to the steering rules. When you have a large rulebase that includes
both steering rules and security policy rules, it might become difficult
to manage both types of rules as you scale.
Post-Rules—separating your security policy rules used for inspection and enforcement from the
security rules used to generate NSX-T steering rules can help you scale in
deployment with a large number of rules. When you auto generate your steering
rules, the plugin generates a steering rule for every rule in the specified
rulebase that meets the necessary criteria. Therefore, by separating the two
types of rules, you can prevent unintentionally generating extraneous steering
rules. Use of the post rulebase for steering rules is recommended; especially in
deployments with large amounts of security policy rules.
The source and destination Dynamic Address Groups you specify in the security rule. When you auto
generate a steering rule, where the rule is applied (NSX-T Distributed Firewall or
Security Group) depends on the source and destination you specified when configuring the
security rule. If you selected any for the source or destination, NSX-T Manager applies
the steering rule to the Distributed firewall. If you select a Dynamic Address Group for
the source and destination, the steering is applied to the guest VMs in those security
groups. If you manually create steering rules, you can specify the security groups where
the steering rule is applied.
Ensure that your security policy that is used to define steering rules don’t include Dynamic
Address Groups configured as part of an operations-centric deployment workflow. If you
do, the steering rules source and destination will be pushed to NSX-T Manager as
source-any and destination-any. This might impact traffic in your NSX-T environment.
If you disable a security rule that you will use to auto
generate a steering rule, the steering rule will be disabled as
well.
