https://redmine.pfsense.org/issues/16868

I've been able to instantly reproduce this issue by simply converting the static route's destination back to an alias (from the working literal IP block). Upon save, the static route disappears.

I only have a single /16 in there right now, the Alias is more about identification rather than convenience. I do have some aliases that have dozens and dozens of records, but this is not one of them.

Still stumped on this one.

In particular

• do you have duplicate entries in an alias. Changing one of the duplicates eliminates the IP completely from the alias
• what is the total number of IP in all of your aliases. Pfsense silently stops entering IP in its tables when it reaches it’s limit. Which entries that is varies with calculation order

Are you saying some part of the resolution mechanism might be case-sensitive but case can be lost

Yes. Lost casing is all I could corroborate.

I can't say anything about potential mismatches as I'm not 100% sure aliases are case insensitive (although, based on this, I assume they are).

In my scenario, the case was "correct" in the Routes page, including caps, since it pulled in the alias via auto-suggest.

My scenario is different in that the auto-suggested alias, and the alias itself following selection, appear with correct casing on the "Edit Route Entry" page/in the "Destination network" field—but display with lost casing in the list of static routes, as captured in my earlier reply.

I feel like I vaguely remember needing to reboot in-between manual-static-route-using-network-alias creation. But that would've been a long time ago. Have you confirmed whether a reboot after creating the static route sees it get installed properly? (Strike that, you mentioned specific use case in OP.)

In my scenario, the case was "correct" in the Routes page, including caps, since it pulled in the alias via auto-suggest.

Something else is off, as I tested this at least 6 times and it will not create the static route if it's an alias. As soon as I switched to a literal IP, it worked reliably every time.

The aliases otherwise 'resolve' properly and the static routes install correctly, so I've chalked it up to a webConfigurator formatting bug. But there could be more here.