Unexpected alias behaviour - two ranges

SteveITS

@tinfoilmatt said in Unexpected alias behaviour - two ranges:

What, pray tell, is a "partially filled alias"?

OP says they are not filling completely:

@Patch said in Unexpected alias behaviour - two ranges:

IP_set1 : host type, 50 IPv4 hosts (/32) and at least 1 FQDN
IP_set2 : host type, 512 IPv4 hosts (/32) and at least 1 FQDN
IP_set3 : host type, 50 IPv4 hosts (/32) and at least 1 FQDN

Diagnostic -> tables -> records: Combined_IP = 256, IP_set1=50, IP_set2=206, IP_set3=0

...should have ~~612~~ 615, has 256. Which seems like a suspiciously specific number, tbh.

tinfoilmatt

@SteveITS said in Unexpected alias behaviour - two ranges:

OP says they are not filling completely:

An alias either is, or is not. When alias creation fails it's either due to parser logic error and/or a user input error. I thought we'd establised the latter as an errant space.

tinfoilmatt

@SteveITS Doing that math also, it would seem that there's an error—not necessarily a software bug—somewhere in there, sure.

Parsing of "IP_set1" has most likely invalidated the FQDN for some reason (is the conclusion requring the least number of assumpions at least). And now all bets are off with the remaining two, and then of course with the "Combined_IP" nested alias too.

If I was being paid to resolve this on behalf of a client, I would establish the end goal intent—and then blow everything out and start over.

stephenw10

A partially populate table is probably a better description here. That's what I saw when I hit it temporarily.

Entering an range of IP addresses as a single line in a host alias is a valid entry. For example: 192.168.1.26-192.168.1.58

What's not expected is multiple subnets as a single line in a host alias like: 192.168.10.0/24 192.168.48.0/24. That's not a range.

But it looks to be possible to hit this using only valid host aliases. There is a bug here IMO it just needs better defining to fix. Working on it....

tinfoilmatt

@stephenw10 said in Unexpected alias behaviour - two ranges:

That's what I saw when I hit it temporarily.

Were/are these the relevant steps?

Create an Alias (host type).
Add a FQDN and two /24 networks one of which includes [one of] the FQDN IPv4 address.
Save and apply.
Look at the filter reload screen,
When complete look at the created table for the Alias.

SteveITS

@tinfoilmatt There were steps above...https://forum.netgate.com/topic/199152/unexpected-alias-behaviour-two-ranges/26

As I understood it (if I followed) some additional key details were:

all child_aliases to be put in the parent_alias needed 1 FQDN, to trigger this
then restore the new configuration (or reboot?)

The restore of course reboots. As I understand the report, it is a latent problem until the reboot when the alias was no longer fully populated.

A general usage example (not tested here but used in my other thread), we have an alias that has aliases containing IPs of our clients as well as various dynamic DNS IPs. Obviously we don't want to set up the same rules for each so a nested alias makes sense.

tinfoilmatt

@SteveITS This thread is lacking in coherent, reproducible steps which demonstrate anything. Not picking on you as you're not OP. But Stephen most recently reaffirms that, at one point, he was able to do—something. In this post he referred to it as "case 2".

That's what I'm wanting to try to recreate for myself.

Patch

@SteveITS said in Unexpected alias behaviour - two ranges:

I am curious, does it matter where the FQDN is, in your alias? Does it stop updating the alias after the FQDN, if it is listed first or last?

Starting from https://forum.netgate.com/post/1229337
In practice I have entered a FQDN then many actual IPv4 addresses. I have mostly used a fixed prefix such as 201 or 202 or 203 (using a different number for each IP_set alias consists almost) followed by random numbers (0-255). It is far easier to add sequential IPv4 addresses but I was unsure what optimisation pfsense does so avoided that.

These IP_sets are then combined in Combined_IP alias (nested / hierarchical)

The bug is revealed on full alias rebuild. In testing I used a configuration restore to ensure repeatability and clear starting point. Restarting pfsense has trigger it in my active systems.

Using 3 IP_sets containing 50, 512, 50 IP addresses,
for me it happens every time within a 30 sec of pfsense starting up. Smaller IP_set sizes can fail less cleanly. Tested with a clean install pfsense v2.81 and v2.72.

@SteveITS said in Unexpected alias behaviour - two ranges:

...should have 612 615, has 256. Which seems like a suspiciously specific number, tbh

I agree that's a suspicious number but if I use 2 IP_sets the number is larger and with other IP set sizes the Combined_IP varies slightly.

@stephenw10 said in Unexpected alias behaviour - two ranges:

A partially populate table is probably a better description here.

That's a reasonable term.

Looking at the Resolver logs the missing alias table entries appear to correspond to

said in Unexpected alias behaviour - two ranges:

IP_set3 table is empty however the log shows the actual 50 IP addresses are added but duplicates of "Adding Action: pf table: IP_set3 host:" but I think all 50 appear.

Similarly "Adding Action: pf table: IP_set2 host: " shows some duplicates. Not all actual IP addresses appear in the 2000 log entires. I was not able to readily tell if all 512 appear at least once in Adding Action: pf table: IP_set2 host:

tinfoilmatt

@Patch said in Unexpected alias behaviour - two ranges:

These IP_sets are then combined in Combined_IP alias (nested / hierarchical)

It's nested.

tinfoilmatt

If anybody can distill two posts above this one, I'm happy to test.