2.5 Access Rules: Fields, Actions, and Track Options

The Anatomy of an Access Rule

Every rule in an Access Control layer has the same core fields, visible as columns in SmartConsole's Access Control rulebase:

A rule matches when all of its match fields match the connection — Source AND Destination AND Service AND VPN AND Time. If any match field does not match, the rule does not match and evaluation moves to the next rule.

Match Fields in Detail

• Source and Destination accept any combination of: single IP, network object, address range, group of objects, or the special Any object. They can also include identity-aware objects when Identity Awareness is enabled — for example, a group named Finance-Users populated from Active Directory.
• Service defines the protocols and ports. R82 ships with hundreds of built-in services (http, https, ssh, dns, smtp, sqlnet, etc.) and supports custom services. Groups of services can be used to match multiple ports in one rule.
• VPN restricts the rule to traffic arriving over a specific IPsec VPN community. Setting VPN to Any means the rule applies regardless of whether the traffic arrived over VPN.
• Time binds the rule to a configured Time object (for example, business-hours). Outside the schedule, the rule is skipped during evaluation.

Actions in R82

The action is the most-tested field. The five primary actions are:

• Accept — allow the connection. Evaluation typically continues to the next ordered layer and then to Threat Prevention for accepted traffic.
• Drop — silently discard the connection. No response is sent to the source. Evaluation stops; subsequent ordered layers are not evaluated.
• Reject — discard the connection and notify the source. For TCP, the gateway sends a RST; for UDP, it sends an ICMP port-unreachable. Evaluation stops. Reject is useful when you want the source to know its traffic was refused (helps users notice a misconfiguration quickly) but it leaks slightly more information than Drop.
• Inform — log the connection without enforcing the rule's action; the connection continues as if the rule had not matched. Useful for monitoring traffic that you do not want to enforce yet.
• Ask — prompts the user (typically through a Captive Portal or UserCheck) before applying the rule. Used with Identity Awareness to interactively confirm access.

A rule can also have an action of Inline Layer (invoke a nested inline layer) or Drop with Reason (a Drop variant that includes a textual reason in the log).

Drop vs Reject

The Drop-vs-Reject distinction is a CCSA staple. Drop is silent: the source sees its packets disappear into a black hole and must time out. Reject is explicit: the source receives a TCP RST or ICMP unreachable and learns immediately that the connection was refused. Security best practice generally prefers Drop for Internet-facing rules because Reject confirms to an attacker that a firewall is present and can leak protocol information. Reject is more user-friendly for internal users who misconfigured a destination and would benefit from immediate feedback.

Track Options

The Track field controls logging and alerting when a rule matches:

A common pattern is to set Accept rules to Log and Drop rules to Log or Alert, so the firewall has a complete picture of allowed and denied traffic. Drop rules that match suspicious or repeated scans are often set to Alert or Mail for proactive notification.

Install On and Time

The Install On field lets a rule target specific gateways. By default, the field is set to All Gateways, meaning every gateway that receives this policy package enforces the rule. You can restrict a rule to a specific gateway or group of gateways, useful for rules that reference interfaces or networks present on only one gateway.

The Time field binds a rule to a Time object. A rule with a Time object of Business-Hours only evaluates during those hours; outside the schedule, the rule is invisible to evaluation. This is useful for change windows, after-hours access, and time-based partner access.

Worked Example

A rule with:

• Source: Net-Internal
• Destination: Net-DMZ
• Service: http
• Action: Accept
• Track: Log
• Install On: All Gateways
• Time: Business-Hours

…matches HTTP connections from internal hosts to the DMZ during business hours, accepts them, logs the connection, and applies on every gateway that receives the policy package. Outside business hours the rule does not match, and the connection falls through to subsequent rules — likely the cleanup Drop at the bottom of the layer.

Best Practices

• Be specific in match fields. Use the smallest scope that satisfies the requirement; avoid Any in production rules where possible.
• Track every security-relevant rule. Log Accept and Drop at minimum; use Alert for sensitive rules.
• Document with Comments. Include a change ticket ID or rationale for every non-obvious rule.
• Prefer Drop over Reject on Internet-facing rules to avoid leaking firewall presence.
• Use Time objects for temporary access so the rule automatically deactivates.

Why This Matters for the Exam

Expect questions that present a rule and ask what happens to a connection: which field matched, what action was applied, what was logged, and whether evaluation continued. Read every field of the rule, not just the action — a rule with the wrong Time or Install On setting may not match at all.