Firewall groups let you define reusable collections of ports or network destinations and reference them throughout the system. Instead of entering the same ports, IP networks, or domain-based targets in multiple places, you can create a group once and use it anywhere it is needed. This makes policy easier to read, faster to maintain, and less error-prone as your configuration grows.

Firewall groups can be used in several areas of the system, including firewall rules, NAT, and policy-based routing (PBR). This allows you to define common match criteria once and apply them consistently across security and routing policies. For example, you might create a port group for a service utilizing multiple ports, an IPv4 network group for trusted internal subnets, or a domain-based group for traffic that should follow a specific WAN path.

The available firewall group types are:

• Port Group: A reusable set of TCP and/or UDP port numbers or ranges.
• IPv4 Network Group: A reusable set of IPv4 networks, addresses, and supported hostname/domain entries.
• IPv6 Network Group: A reusable set of IPv6 networks, addresses, and supported hostname/domain entries. 

Port groups are straightforward and are typically used when matching traffic by destination or source port in firewall, NAT, or PBR rules. They can contain individual ports, or dash-delimited port ranges.

IPv4 and IPv6 network groups support more than just static IP addresses and subnets. In addition to standard network entries, they also support exact hostnames and wildcard domains. These domain-based entries are handled differently depending on the type of match.
 

For exact hostnames, the system uses an Alta proprietary backend which resolves the hostname, populates Route10’s DNS cache which is also used by network clients pointed to Route10 for their DNS, populates the firewall group, and keeps that group updated if the DNS answers change over time. The DNS record is refreshed, and group updated as needed, when the DNS TTL expires. This is the best choice when you want a policy to follow a specific fully qualified hostname which is kept current as IPs change.
 

For wildcard domains, the backend uses the firewall group integration in the Alta Router’s DNS resolver. In this case, matching IPs are learned only when a client queries a hostname that matches the wildcard. When that happens, the returned addresses are added to the relevant group. Because of this, wildcard domain matches are demand-driven: they do not populate proactively, and they depend on clients using the router for DNS resolution. If no client has queried a matching hostname via the router, the corresponding IPs will not be present in the group. It’s important to ensure clients are using Route10 as their DNS server, or if you have internal DNS servers they use Route10 for all internet queries.
 

This distinction is important when deciding which type of entry to use. Exact hostnames are actively managed and kept current by the backend. Wildcard domains are more flexible for broad matching, but they rely on observed DNS activity and may not match traffic until the relevant domain has been queried through the router. It is possible to thwart policies/rules using wildcard entries if the client uses DNS-over-HTTPS instead of the Alta Router for DNS, whereas explicit hostnames are less likely.

Using firewall groups is especially helpful when building larger or more dynamic policies. A single group can be referenced by multiple rules, so updating the group updates every policy that depends on it. This reduces duplication and makes ongoing administration much easier.

Common Use Cases

• Reusing the same service ports across multiple firewall rules.
• Defining destination networks for NAT policies.
• Source-restricting port forwards.
• Sending traffic for specific networks or domains through a chosen WAN using PBR

Things to Keep in Mind

• Wildcard domain entries depend on DNS queries being handled by Route10. Clients cannot point to anything else as their DNS server unless that DNS server itself uses Route10 to answer internet DNS queries.
• Exact hostname entries are managed proactively by the backend.
• Domain-based matches depend on DNS resolution and resulting group membership, not on inspecting the domain name directly in the traffic itself. For the most common use cases, it isn’t viable to pull domain names directly from the traffic - they frequently are not present there at all, and where they are, it’s often too late to take the desired action by the time they are visible (such as the impossibility of changing the WAN of an already-established connection).

Example Scenarios

Routing a Domain to WAN2

In this example, we will route *.example.com out of WAN2. Remember this means the clients must be pointed to Route10 for their DNS, which is done by default, but this cannot work if the clients are pointed to other DNS servers.

Creating Wildcard Domain Group

First we’ll create the *.example.com firewall group. Browse to Settings > Firewall > Firewall Groups. Click Add.

Name: as you like. I went with “All example-com” to abide by the group name character restrictions.

Type: IPv4 Network

Contents: *.example.com

Click Save, and close the group window.
 

Keep in mind that this rule is only for IPv4. If you want to route IPv6 traffic for this domain over a specific WAN, you would need a similar IPv6 rule, as well.

Adding PBR Rule

Now browse to Settings > Firewall > Policy Routing. Click Add.
 

Name: example.com to WAN2

Protocol: Any

Source: Any

Destination: “All example-com” group

Sticky: Disable

Target: WAN2

Then click Save, and you can close the PBR rule window. Now every IP result from resolution of *.example.com hostnames will use WAN2.

Source Restricted Port Forward

For this example, we want to port forward a web server only for traffic sourced from the dynamic DNS hostname ddns.example.com. This is vastly safer than opening a port to the entire internet since it keeps your attack surface limited to only the IP(s) the hostname resolves as. Ideally a VPN is a better option to use, but for cases where that is not viable, a source restricted port forward provides much better security than a wide open port forward.

Note: you cannot use a wildcard domain for this use case, since there is no assurance any client will perform the necessary lookup to populate the group. Exact hostnames are populated automatically on the back end.

Creating Network Group

Browse to Settings > Firewall > Firewall Groups, and click Add.
 

Name: name it as desired, I’ll call it My DDNS

Type: IPv4 Network

Contents: ddns.example.com

Then click Save, and close the firewall group window.

Adding Port Forward

The web server we’re opening is at 192.168.1.10, and we’ll open only HTTPS on TCP 443. Browse to Settings > Firewall > Port-forward/NAT. Click Add.

Name: however desired, I’ll call it Restricted web fwd

Type: Port-Forward/Dest

Protocols: TCP

Source: My DDNS group

Source Port: Any. Do not choose 443 as the source port as that will not work. Source ports for HTTPS are random from the ephemeral port range.

Destination: If you have a single WAN IP, choose Any. If you have multiple public IPs, choose Custom and enter the specific one you want to use.

Destination Port: Choose Custom and enter 443.

Redirect to: 192.168.1.10:443

Zone In: WAN

Zone Out: LAN

Then click Save, and your restricted-source port forward will be enabled.

VoIP Port and Network Group Example

One potential use case which combines a port group, and two network groups is restricting IP phones. Here we have a dedicated VoIP VLAN on 192.168.2.0/24. The phones use the standard SIP and RTP ports, and communicate with a cloud PBX at pbx.example.com. We will configure firewall rules so these phones can only communicate with the PBX using the VoIP ports, and block all other traffic from that network.

Creating Port Group

First we’ll add a firewall group containing the standard SIP (5060) and RTP (10000-20000) ports. Browse to Settings > Firewall > Firewall Groups and click Add.
 

Name: click the pencil at the top to edit the name. We’ll call this VoIP Ports.

Type: choose Port

Contents: 5060 and 10000-20000

Then click Save and close the VoIP Ports group window.

Creating Source Group

Click Add to create the source group specifying the VoIP VLAN’s subnet. 
 

Name: VoIP Network

Type: IPv4 Network

Contents: 192.168.2.0/24
 

Then click Save, and close the group window.

Creating the PBX Group

Now click Add to add a group for the cloud PBX using its pbx.example.com hostname.

Then click Save, and close the group window.

Creating Firewall Rules

Now let’s create the firewall rules using the groups we just created. Browse to Settings > Firewall > Filter. Click Add there to add the first rule, the one permitting the phones to reach the PBX.
 

Name: Allow VoIP network to PBX

Protocols: UDP

Source: VoIP Network group

Source Port: Any. Note that source port is almost never the same as destination port, rather is a random port from the ephemeral port range, and hence should be left to Any. Do not choose the VoIP Ports group here.

Destination: PBX group

Destination Port: VoIP Ports group

Zone In: LAN

Zone Out: WAN
 

The remainder can be left at defaults.

Click Save.
 

Now click Add again, and we’ll add a rule to block all other internet-bound traffic from the VoIP network.
 

Name: Block VoIP network to internet

Protocols: Leave blank to match all

Source: VoIP Network group

Destination: Any

Zone In: LAN

Zone Out: WAN

Action: in the bottom left corner choose the X icon for reject, or down arrow for drop. Reject is generally preferable for internal networks, so we will choose it here.

Then click Save, and you can close the firewall rule window.
 

This leaves you with the following two rules in the filter rules list.

It’s important to maintain the allow, then block order. If you reordered the rules so the block came before the allow, then all traffic from the VoIP network would be blocked, and the phones would not be permitted to reach the PBX. First matching rule wins.