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 $gt; Firewall Tables to see your current tables.

Screenshot: Manage Tables view

Step 2: Add or Modify a Table #

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

Screenshot: Select a Firewall Table

Screenshot: Edit Table Entries

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.

Screenshot: Protocol Rules with Tables in Use

Look at the “Source” field — instead of a single IP, it references The InternalServers Firewall Table.

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’ll want to use it within your protocol rules to control traffic.

How Tables Appear in Rules #

Go to Firewall > Protocol Rules, and scroll through the list. If firewall tables are in use, you’ll see rules that reference them directly, like so:

Screenshot: Protocol Rules referencing firewall tables

Look at rules numbered 190 — each of these references a different Firewall Table:

• 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 (e.g., The InternalServers Firewall Table) to jump directly into that table for editing or review.

• This is especially 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 needing to dig 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 for administrators 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

Example: MailServers Presets #

Within the MailServers table, you’ll find DNS entries for major email providers like:

Service	Type	Hostnames
Gmail	DNS	imap.gmail.com, smtp.gmail.com
Outlook.com	DNS	smtp-mail.outlook.com, pop3.live.com
iCloud	DNS	mail.me.com
Office365	DNS	smtp.office365.com, outlook.office365.com

These are commonly needed to allow outbound mail clients to function correctly.

Example: STUNServers Presets #

To support Google Meet and other video conferencing tools, the STUNServers table includes:

Service	Type	Entry
Google STUN	DNS	stun.l.google.com (and others)
Google Media IPs	IP Address	74.125.250.0/24

These entries help with NAT traversal and call setup.

Tip: You don’t need to manually add these unless you need additional entries. Just go to Firewall > Firewall Tables, click Manage Table Entries, and activate the ones you need.