pfSense

Using aliases in static routes is a nice thing as it makes handling those a bit easier by grouping your networks first, then adding a single static route entry for multiple networks.

Unfortunately there are a couple of issues:

Tested with: 2.4.4-p3 and 2.5-snapshot-current
Environment: Lab Test VM

1) Adding a route with a network alias
-> works fine!

2) Renaming the network alias:
!> route stays online but looking into System/Gateway/Static Routes section, there's still the old Alias name
!> Rebooting in that state, the system comes up normally but looses the broken route as the alias won't get fixed
=> Renaming an alias isn't copied over to static routes as it is for e.g. filter rules or NAT entries

3) Editing the alias content:
!> If I change the content of an alias e.g. changing the network from 10.20.30.0/24 to 10.20.31.0/24 the route isn't updated
!> After a reboot the route is changing. Also editing the static route and just saving it again will fix this but it isn't done automatically which is a different behavior then in all other cases (rules, NAT, etc.)

4) aliases in aliases:
> adding a static route with an alias that in itself has two other network aliases is fine
> all networks are added as a static route to the selected gateway
!> changing the content of the inside aliases will be ignored as above, the added routes aren't changing
!!> after manually editing/re-saving the alias'ed static route, the new content will be added as routes, BUT the old ones won't get deleted.

Example:

- N4_lab_test > host alias, consists of N4_lab_dummy1 and N4_lab_dummy2
N4_lab_dummy1/2 > network alias, consists of a dummy net like 10.10.10.0/24, 10.10.20.0/24
add static route with N4_lab_test to some Gateway => routes are created for 10.10.10.0 and 10.10.20.0 to said GW
- edition the dummies to 10.10.11.0 and 10.10.21.0 => routing table still only has network routes for 10.10.10.0/24 and 10.10.20.0/24
- edit&save static route with N4_lab_test => routing table has routes for ...10.0, .11.0, 20.0 and 21.0 as the old ones didn't get deleted and the new ones only added.

Playing that game makes your routing table grow without a chance to stop it (besides manual interception on the command line and some "route del" magic).

So I see two possibilities:

1) dependency handling for static route dialog to include reactions and blocks for alias changes (delete action is already blocked when using an alias in routes, so edit changes should also trigger a hook to check for routing changes and edit the routing table accordingly)
2) removal of aliases in static routes (would be sad to see that go)

As a side note: I'm really missing the "red fields" to indicate a field that aliases can be used in. It's often a trial and error thing if one can use aliases in certain conditions or not. Like they can be used fine in port forwards but not in a 1:1 NAT rule but can then be used as a target or source in outbound NAT rules again. Perhaps a small symbol next to or in the text field to indicate the possible use would be nice if color isn't a good choice anymore (never came back after switching to the bootstrap theme).

Greets
Jens