Possible Bug? Aliases in Static Routes not resolving
-
I know this feature is supposed to work, it's even in the docs!
On 26.03.01, I have a static route that I need to use for an IPsec VTI tunnel configured in System > Routing > Static Routes
The destination was an alias, and the gateway was the IPsec endpoint (unmonitored, it doesn't respond to pings).
Every reboot, the static route did not get installed, and thus traffic to and from the tunnel was silently dropped. Restarting IPsec somehow caused the alias to resolve and work, and the route appeared.
I was able to work around this by using the literal IP and mask - this makes it work every time. But it seems apparent that using an alias here is supposed to work, and I have tested this over and over again, with two different pfSense boxes on this release (FWIW 26.03 also has this behavior) and it's not working as documented.
Anyone else seeing this behavior? Wanted to check on it here before filing a bug report.
Thanks in advance.
-
Potentially relevant, potentially not—but I've been seeing the following on CE for as far back as 2.5 or earlier:
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.
-
@tinfoilmatt Are you saying some part of the resolution mechanism might be case-sensitive but case can be lost, causing a potential mismatch?
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.
-
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.) -
@MasterYous aliases can have unexpected behaviour in pfsense, see https://forum.netgate.com/post/1231744
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
-
@Patch Thanks for replying.
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.
-
Following up: I opened a TAC issue on this, as this behavior is worrisome. I will update the forum with that support status when we reach a resolution.
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.
-
TAC confirmed this as a bug. For anyone interested:
https://redmine.pfsense.org/issues/16868
