# Default elements for Access rules

There are several predefined elements for configuring Access rules.

## Default elements for Engine Access rules

There are two predefined Firewall Template Policies called Firewall Template and Firewall Inspection Template. They contain the basic Access rules that allow communications between the engine on which the policy is installed and other SMC components. The Firewall Inspection Template is based on the Firewall Template.

You must use one of the predefined Firewall Template Policies as the basis for defining your own templates and policies. It is not possible to create a new template at the highest level of the policy hierarchy. No changes can be made directly to the predefined Firewall Template Policies. However, you can create your own copies of the predefined Firewall Template Policies if you have a specific need to edit the rules in them.
Note: If you use a copy of a predefined Firewall Template Policy, you may have to adjust your rules manually when the system is upgraded to account for changes in system communications. Upgrades can change only the predefined Firewall Template Policies, not the copies.

There is a yellow row near the end of the list of rules on the IPv4 Access and IPv6 Access tabs in the predefined Firewall Template Policies. The yellow row marks the insert point, where rules can be added in the inheriting Engine Policy and Firewall Template Policy elements.

The rules above the insert point detail the various kinds of system communications. Most of the IP addresses are defined using Aliases to make the rules applicable on any system where they are installed. These Aliases are default elements. The Service cell is the best starting point for understanding in greater detail what these rules do.

There are two rules below the insert point. The rule directly below the insert point has the action Refuse for the Ident protocol traffic. This action stops the traffic and sends an ICMP error message to the Ident request sender. This rule exists to prevent Ident requests from being silently dropped (as the next rule specifies for all other traffic). Silently dropping Ident requests might cause delays in legacy environments where the Ident protocol is used. The last rule before the end of the policy is a rule that discards all traffic and creates a log entry that is stored. This rule’s purpose is to make sure that this connection dropping is logged. This rule is important because the engine silently drops the connection without creating a log entry if the matching process reaches the end of the policy.

## Default elements for IPS and Layer 2 Engine Access rules

The IPS Template and the Layer 2 Firewall Template have predefined Ethernet rules, IPv4, and IPv6 Access rules. Because the default policy elements are introduced when you import and activate a recent dynamic update package, the templates you currently have in your SMC might look slightly different from the one that is presented in this section. Newer versions of the templates work in the same way as described below. Any changes to the templates are documented in the Release Notes document for each dynamic update package.

There are several IPv4 and IPv6 Access rules with various Services defined with Continue as the action and a yellow insert point indicating the place where a Policy that uses the template can be edited.

The Access rules that you add at the insert points in custom policies based on the IPS Template or the Layer 2 Firewall Template are usually specific exceptions to the rules inherited from the template. For example, you could insert a rule there that allows a connection between two particular hosts to continue without any further inspection. Or, you could instert a rule for inline IPS engines to always stop traffic between particular IP addresses and ports.