---
title: Using Firewall Tables to Simplify Rule Management in SecureSchool
description: "## 📖 Overview **Firewall tables** allow you to group related IP addresses and reference them in firewall rules. This dramatically reduces rule clutter, especially in environments with multiple servers, subnets, or devices that share similar access needs. Instead of writing…"
url: "https://www.k12usa.com/docs/using-firewall-tables-to-simplify-rule-management-in-secureschool/"
updated: "2026-02-07"
category: SecureSchool
tags:
  - SecureSchool
---

# Using Firewall Tables to Simplify Rule Management in SecureSchool

## 📖 Overview

**Firewall tables** allow you to group related IP addresses and reference them in firewall rules. This dramatically reduces
 rule clutter, especially in environments with multiple servers, subnets, or devices that share similar access needs.

Instead of writing the same rule over and over for each device, you can:

- Create a table of IPs or subnets
- Apply one rule to the whole group

---

## 🔎 When to Use

Use firewall tables when:

- You have multiple internal servers needing identical access rules.
- You want to group IPs by function, location, or network segment.
- Your firewall rules list is getting long or repetitive.
- You want to simplify future changes (update one table, affect all related rules).

---

## ⚙️ How It Works

A firewall table is a **named group of IPs or subnets**. Once defined, these tables can be referenced inside protocol rules.

**✅ Benefits:**

- Keeps your rule list shorter
- Centralized changes — update one table, not 12 rules
- Easy to audit or expand access groups

---

## 📝 Example: Internal Servers

Let’s say you currently have this:

| Rule | Source | Destination | Description |
| --- | --- | --- | --- |
| 1 | 192.168.100.10 | Any | Allow web server |
| 2 | 192.168.100.11 | Any | Allow mail server |
| 3 | 192.168.100.12 | Any | Allow DNS server |

That’s **3 rules doing the same thing** — one per device.

**With a firewall table:**

- Create a table called **InternalServers**
- Add all 3 IPs to it
- Write one rule: **Allow from InternalServers to Any**

---

## ➕ Creating and Managing Firewall Tables

### 🔧 Step 1: View Existing Tables

Go to **Firewall → Firewall Tables** to see your current tables.

### ✍️ Step 2: Add or Modify a Table

Click **Manage Table Entries** to view or edit the contents of a table.

You can:

- Add new IP addresses or subnets
- Set expiration (“Until”) dates if needed
- Deactivate or remove entries

### ⚙️ Step 3: Use the Table in a Rule

Now go to **Firewall → Protocol Rules** and select (or edit) a rule.
 In the **Source** field, you can choose a firewall table instead of a single IP address.

Example: A rule might reference **The InternalServers Firewall Table** as the source.

---

## 💡 Best Practices

- ✅ Use tables for anything you repeat in more than 2–3 rules
- 🏷️ Name tables clearly (e.g., **MailServers**, **RemoteAdmin**, **ProxyExceptions**)
- 🧹 Periodically review and clean up entries
- 🧪 Test table-based rules after migrating from individual entries

---

## 🧾 Troubleshooting

- 🔍 If traffic isn't working, confirm the IP is listed in the table and the rule is active
- ⚠️ Deleting a table or entry affects all rules that reference it
- 🧪 Try adding a test entry before migrating full sets of rules

---

## Using Firewall Tables in Protocol Rules

Once you've created a firewall table (like **InternalServers**), you can use it within your protocol rules to control traffic.

### 🔗 How Tables Appear in Rules

Go to **Firewall → Protocol Rules**. If firewall tables are in use, you’ll see rules that reference them directly.

For example, you might see rules that reference different firewall tables such as:

- InternalServers
- MailServers
- NTPServers
- ProxyExceptions
- RemoteAdmin
- STUNServers

Each of these rules allows traffic from the respective table, rather than from individual IPs.

### 🧭 Viewing or Editing the Table Behind the Rule

You can click the table name (for example, **The InternalServers Firewall Table**) to jump directly into that table for editing or review.

- This is helpful if you're not sure what's inside the group.
- From there, you can add, edit, deactivate, or remove entries as needed.

📌 This makes it easy to audit a rule’s actual scope — without digging through IPs manually.

---

## Example Use Case: InternalServers

If a protocol rule allows traffic from **InternalServers**, and that table contains:

- 192.168.100.28
- 192.168.100.30
- 192.168.100.31

Then all of those servers are granted the same access by that one rule.
 If you need to add a new server, just add its IP to the table — you don't need to write another rule.

---

## 🧰 Preset Entries for Common Services

Some firewall tables — like **MailServers**, **NTPServers**, and **STUNServers** — come preloaded with commonly used service entries.
 This makes it easier to allow trusted, essential services without having to manually look up and enter server addresses.

**These entries are:**

- Predefined and labeled (e.g., Gmail, Outlook)
- Managed by SecureSchool (you can't edit or delete them manually)
- Can be activated or deactivated with one click

###