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

Alias bug: dashed IP range vs CIDR IP range

Firewalling
alias rules bug portforward port forward
2
4
957
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 Mar 28, 2019, 4:12 AM

    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
    • J
      jimp Rebel Alliance Developer Netgate
      last edited by Apr 1, 2019, 5:10 PM

      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 Apr 1, 2019, 5:50 PM

        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
        • J
          jimp Rebel Alliance Developer Netgate
          last edited by Apr 1, 2019, 5:58 PM

          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
          1 out of 4
          • First post
            1/4
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.