Host, network and port aliases — naming and when to use

A firewall rule that says “permit 192.0.2.50 to 203.0.113.50” is a single line; a rule that says “permit dmz_servers to backup_targets” is an object the team can edit, audit, and reuse. Aliases are the named address sets that make OPNsense rulesets maintainable. The operator who uses them well writes rules that survive address changes, ownership transfers, and audits; the operator who does not use them writes the same rule in twelve places and changes twelve rules when one IP moves.

OPNsense exposes three alias types — Host, Network, and Port — and a fourth type, URL Table, that fetches its contents from a remote source. This lesson covers the three local types. The next lesson covers URL Tables in depth.

The three alias types

A Host alias is a named set of single IPv4 or IPv6 addresses, optionally with Fully Qualified Domain Names (FQDNs). A Network alias is a named set of subnets (CIDR blocks). A Port alias is a named set of port numbers or port ranges. Each alias type maps to a specific PF construct — Hosts and Networks map to a PF table, Ports map to a match against a port set in a rule.

A rule that references one of these aliases compiles to a table <alias_name> declaration in the generated ruleset and a from <alias_name> or port <alias_name> matcher in the rule. The compile step is part of the filter generator (filter_generate.inc) described in the lesson on the generated configuration.

$ pfctl -t dmz_servers -T show

   203.0.113.10
  203.0.113.11

Host aliases — single addresses and FQDNs

A Host alias holds one or more IPv4 or IPv6 addresses. It can also hold Fully Qualified Domain Names, which OPNsense resolves to addresses on a refresh interval. The resolved addresses populate the table; the FQDN itself is not matched in the rule, only the resolved addresses.

Three production patterns show up repeatedly:

• Static service IPs. A small set of addresses that does not change often.
• FQDNs for cloud endpoints. Cloud service IPs change.
• Indirection for ownership. A team owns an alias; when the team changes the IPs, the rule does not change.

Network aliases — subnets and CIDR blocks

A Network alias holds CIDR blocks. The compiled ruleset matches any packet whose source or destination is in any of the blocks.

A few rules of thumb:

• One alias per logical group. “All DMZ networks” — fine. “DMZ networks and partner networks and dev networks” — split it.
• Match the smallest meaningful block. An alias that holds 10.0.0.0/8 is almost never what you want.
• Consider the alias boundary. A Network alias is an address matcher; it does not imply routing or interface membership.

Port aliases — ports and ranges

A Port alias holds port numbers and ranges. The compiled rule uses the alias as a port = <alias_name> matcher.

The production traps:

• Mixed transport. A Port alias applies to TCP and UDP simultaneously unless the rule constrains the protocol.
• Range overlap. Aliases can hold overlapping ranges. PF evaluates the alias as a set, so overlaps are harmless but they make auditing harder.
• The alias that grew. A Port alias that started with three entries and grew to thirty is a maintenance liability.

Naming conventions that survive turnover

A name like alias_1 or list_A is a maintenance liability. Names should encode three things: what the set is, who owns it, and what it is for.

Two patterns work well:

[purpose]_[scope]_[owner]

dmz_servers_prod
vpn_remote_users
admin_ips_netops
database_ports_appteam

Or, with explicit prefix to indicate type:

h_dns_resolvers        # host
n_office_vlans         # network
p_admin_ports          # port

When an alias is the right tool

Three rules of thumb cover most decisions:

1. One rule, one address. If you have a single rule that references a single address, an alias adds no value. Inline the address.
2. Two rules, one address (or one rule, two addresses). The alias pays for itself.
3. Anything that is “owned” by a team or system. If a team or a system is the source of truth for the addresses, an alias is the contract.

Summary

• OPNsense aliases are Host (addresses and FQDNs), Network (CIDR blocks), and Port (ports and ranges). All compile to PF tables.
• Use Host aliases for service IPs, Network aliases for subnets, Port aliases for port sets.
• FQDN aliases depend on DNS resolution. Stale FQDN resolutions leave stale table entries.
• A naming convention that encodes purpose, scope, and owner survives team turnover.
• Use an alias when two or more rules share an address, or when an external team owns the addresses.