Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Alias bug: dashed IP range vs CIDR IP range

    Scheduled Pinned Locked Moved Firewalling
    aliasrulesbugportforwardport forward
    4 Posts 2 Posters 969 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      mhcptg
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        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.

        Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • M
          mhcptg
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            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)

            Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.