Treat a pfSense route-alias edit as an immediate routing change

Saving an alias used by a static route can update the routing table before Apply Changes.

Source facts

Netgate permits aliases as destinations for pfSense static routes. It explicitly warns that editing such an alias changes the routing table as soon as the alias is saved; the firewall does not wait for Apply Changes. The next-hop router must already exist as a gateway, and routed source networks also need appropriate firewall and NAT treatment.

Source: Netgate — Static Routes.

Applicability

This concerns aliases used by pfSense static routes.

DSE recommendation

DSE recommends identifying all route uses of an alias before adding, removing, or replacing a member. Schedule the alias save itself as the change point and keep a separate management path available. Capture the prior alias contents and routes so rollback is precise. Separate a firewall-only address group from a routing destination alias when their ownership or review process differs. Avoid assuming an unapplied banner elsewhere means forwarding is still unchanged. Name the person authorized to save the alias and ensure the route observer is ready beforehand. For shared aliases, list every affected destination owner in the change plan; stop if the edit also changes a route outside the approved destination set.

Verification

For an approved maintenance change, record the route table immediately before and after saving the alias. Confirm the intended next hop for every affected destination and verify a return path. Check representative unrelated routes as well, then retain the actual transition time in the change record.

Official reference

Netgate — Static Routes. Reviewed October 20, 2026.