Firewall rules and policies
Firewall behavior on the SC//Reliant™ platform is controlled centrally through Firewall Policies in SC//Reliant Platform Manager (RPM) and enforced locally by the Linux kernel firewall (Netfilter/iptables) on each node. This article explains how policies and rules are structured, what's shown in the RPM UI, what fields are available when building a rule, how rule order works, and how container network access is controlled separately from general firewall policy.
Policies, node groups, and rules
Firewall Policies are managed at the node group level: each policy is associated with one node group, and a policy can contain many individual rules — production policies with 50 or more rules are common for larger environments. Policy names should track the node group they apply to for clarity, and policies apply to the node's host-level networking rather than to individual virtual workloads running on it.
Each policy also has its own Active status, independent of its rules. A policy can exist and hold rules while marked inactive — for example, while it's being staged or is no longer in use — without those rules being enforced. Only active policies are applied to their node group.
Viewing and managing policies in RPM
Firewall Policies are found under Services > Firewall Policies in the RPM left navigation, alongside related items like Internet Content Control. The policy list shows, for every policy in the account: ID, Name, node group, number of Rules, and Active status (true/false). From here you can create a new policy, or open an existing one to view or edit it.
A policy's detail page shows its Status (Active/Inactive), node group assignment, Name, and Description, followed by its rule list. The rule list can be filtered by chain (for example, INPUT or FORWARD), and supports searching by rule name. From the detail page you can also view the policy as raw JSON, export its rules to CSV, clone the whole policy (useful for reusing a policy across similar node groups), or delete it.
Building a rule
Clicking + New Rule on a policy's rule list opens a form with a small set of core fields up front, plus a collapsible Additional Fields section underneath for everything else. Each rule also has its own Status (Enabled/Disabled) — a rule can be temporarily disabled without deleting it, independent of whether the parent policy is active.
Core fields
| Field | Description |
|---|---|
| Name | Required. A descriptive label for the rule (for example, "Allow DRBD Sync" or "AWS to Edge Appliance [TCP]"). |
| Status | Enabled or Disabled (defaults to Enabled). Disabling a rule removes it from enforcement without deleting it. |
| Chain | Where in the traffic flow the rule applies. INPUT (traffic destined to the node itself), FORWARD (traffic the node routes between networks), and OUTPUT (traffic the node generates) cover general filtering. PREROUTING and POSTROUTING are used for address translation (NAT) — for example, redirecting inbound traffic to a different destination, or masquerading outbound traffic behind the node's public IP. |
| Action | What to do with matching traffic: Accept, Drop, Reject, Log, and similar actions. |
| Source / Destination address | The network or host the rule matches. Each address field supports multiple values — click Add new value to add another entry rather than being limited to a single IP or range per rule (for example, a rule can match both a unicast and a multicast address for cluster heartbeat traffic). Each value can be a literal address or a reference to an existing RPM property, and each has an Octet Replacement Settings option to substitute specific octets of a referenced property's address — for example, reusing a property's network prefix while specifying a different host octet. For entering many values at once, an Edit using textarea toggle switches the field to a plain text box. |
| Destination port | A single port, a colon-separated range (5404:5405), or a comma-separated list of ports and/or ranges (3142, 8140, 873, 5671, 5672). Also supports multiple entries via Add new value. |
| IP Protocol | tcp, udp, icmp, ah, all, or similar. |
Most address and port fields accept either a typed-in value or a reference to an existing RPM property, so a rule can automatically track a changing IP or interface rather than needing to be edited manually every time.
Additional fields
| Field | Description |
|---|---|
| Order | A number that determines the rule's position within its chain relative to other rules. Rules commonly share the same order value (for example, 100) and are applied alphabetically by name as a tiebreaker; set a distinct value only when a rule specifically needs to be evaluated before or after others that would otherwise tie. |
| Template name | An internal identifier for the rule; not typically something you need to set directly. |
| Table | Which underlying table the rule belongs to (filter for general traffic control, nat for address translation). |
| Source port | A specific port, range, or comma-separated list, matched against the traffic's originating port. |
| In / Out interface | Restricts the rule to traffic arriving or leaving on a specific interface. |
| Tosource / Todest / Toport | Used with NAT rules to specify the address or port traffic is translated to (for example, redirecting inbound traffic to an internal destination, or masquerading outbound traffic behind a specific source address). |
| Reject | The rejection behavior used when Action is set to Reject (for example, the type of response sent back to the sender). |
| Log level / Log prefix | Whether matching traffic is logged, at what level, and with what prefix in the log line. |
| ICMP | Restricts the rule to a specific ICMP message type (for example, ping). |
| Limit | Rate-limits how often the rule matches — useful for keeping a logging rule from flooding logs during a traffic spike. |
| State | Connection state the rule matches (new, established, related). Unlike most other fields, state only accepts a predefined set of values rather than a free-form entry. |
| Redirect | The port to redirect matching traffic to. |
Rule ordering
A small set of default rules is always applied automatically at the very top and bottom of each chain — for example, permitting established management access at the top, and a default log-and-reject at the bottom. Because these defaults already exist, a catch-all "reject everything else" rule does not need to be added manually.
Rule order matters whenever two rules could both match the same traffic. A broad "allow" rule placed ahead of a more specific "deny" rule can unintentionally let through traffic that should have been blocked — for example, a rule that allows a guest WiFi network out to the internet can also expose a corporate network reachable over the same interface unless a more specific deny rule for that path is placed ahead of it. As a general practice, put more specific deny rules before broader allow rules that could otherwise match first. In practice, most rules in a policy share a default Order value (for example, 100); a rule given a distinct value (for example, 101) is deliberately being evaluated after — or before — everything sharing the default.
Container (Docker) network access
Workloads running in containers on a node have their own network access control, separate from general Firewall Policies, called Network Access rules.
By default, no external network can reach a container's exposed ports, even if a broader Firewall Policy would otherwise allow that traffic — container traffic is evaluated before general firewall policy is applied. To allow access, a Network Access rule defines:
- Source network — the network or host address allowed to reach containers (required).
- Protocol — tcp, udp, icmp, or all (optional; defaults to all).
- Destination container network — limits access to containers attached to a specific container network; if left blank, all containers on the node become reachable from that source network (optional).
If no Network Access rule is defined for a given container-exposed port, access to it is denied by default. Enabling or disabling this feature restarts the container runtime on the node — on a clustered node this triggers a failover event — so it's worth planning for a maintenance window when changing it for the first time. Once enabled, adding or editing individual rules afterward does not require a restart. General (non-container) traffic to and from the node continues to be governed by ordinary Firewall Policies as usual.
PCI DSS alignment
Firewall management on the platform is built around PCI DSS Requirement 1 ("Install and maintain a firewall configuration to protect cardholder data"), including restricting connections between untrusted networks and the cardholder data environment, prohibiting direct public access to CDE systems, and keeping firewall policies and procedures documented and current.
Related articles
- Networking overview — segmentation model and firewall rule reference tables
- Web/URL Filtering and the Acceptable Use Policy Portal