Alias bug: dashed IP range vs CIDR IP range



  • I ran into a truly pathological bug in the support for a dashed IP range alias versus a multi-CIDR IP range alias, which took me many hours to track down.

    According to what I have read in the past, PFSense claims to support dashed IP aliases, such as 1.2.3.4-8, instead of having to use 1.2.3.4/30 and 1.2.3.8/32 and whatever other weird small CIDR blocks are needed to include the dashed IP range.

    However, when I create such an alias, and integrate that alias by name into another alias, I am finding that the end alias contains corrupted / missing IPs when you verify it using sudo pfctl -t top_alias_name -T show. After replacing the contents of the dashed IP alias, with the weird CIDR blocks it takes to represent it, the IPs began to properly appear inside of the pfctl output.

    I wanted to see if anybody else ran into bizarre issues like this, and how I might do some more work to help identify the root cause of this issue most effectively so we can get it fixed for others.

    I encountered the issue, when I was finding that some clients specified in a dashed IP range on a NAT rule, were unable to connect to an internal resource via a port forward containing a dashed IP alias inside of the alias used to configure the port forward rule.


  • Rebel Alliance Developer Netgate

    What is the exact input you used to make the alias?

    The format for a "dash" alias isn't short like you showed, it would be 1.2.3.4-1.2.3.8. When saved, it would translate that into an equivalent set of CIDR blocks and it wouldn't store the dash range.



  • Thanks for the eagle eye, Jim. I had used "1.2.3.4-8", which is as you said apparently incorrect, but somehow the system still accepted this input, didn't produce any CIDRs in a conversion, and generated an invalid peer list for the affected alias. Should I file a bug? I am rather curious if somebody can reproduce it in their environment or if I managed to find a one-off somehow.


  • Rebel Alliance Developer Netgate

    It might be an edge case we can't really detect well since it may be valid in some other way, even if it isn't an IP address (e.g. a hostname, other alias name, etc)