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

    Host Alias IP's not exploding into filter rules correctly

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    10 Posts 3 Posters 2.8k 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.
    • J
      jwrascoe
      last edited by

      I noticed in todays snap, 2.0-BETA1 built on Fri Mar 19 05:13:59 EDT 2010 that host IP's defined in an alias do not explode correctly into the filter rules.

      I am running NANO so not sure if its related to that platform.

      If you run cat  /tmp/rules.debug you will see what I mean under the "# User Aliases" section

      Is there a manual work-around to get pfsense to generate the correct info?

      Jim

      1 Reply Last reply Reply Quote 0
      • E
        eri--
        last edited by

        Give full details on what you mean.

        Give examples of what is missing otherwise your universe is not the same as mine.

        1 Reply Last reply Reply Quote 0
        • J
          jwrascoe
          last edited by

          Sure…

          I have defined an alias called "voip" with 2 hosts 192.168.1.11 & 192.168.1.12

          Then I use the traffic shaper wizard & enable the Voice over IP section and provide the "voip" alias in the address section in the user interface... then I press next thru all the other prompts not enabling any of them.. and wait for the filter to reload

          when the filter rules are created it never explodes the "voip" alias into the IP's... thus the traffic never gets put into the correct queue.

          This is how the section gets created.. normally it would have the 2 ip addresses listed to the user alias called voip.. but you will see there are no IP's

          User Aliases

          table <voip>persist
          voip = "<voip>"

          Let me know if you need more detail.. and thank for your help!

          I appreciate it.

          Jim</voip></voip>

          1 Reply Last reply Reply Quote 0
          • E
            eri--
            last edited by

            Fixed, thanks for reporting.
            https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/9e98e1cb653f95837ec93d8c05a0d7efdfabd373

            1 Reply Last reply Reply Quote 0
            • J
              jwrascoe
              last edited by

              Thanks!

              1 Reply Last reply Reply Quote 0
              • J
                jwrascoe
                last edited by

                Humm.. I manually patched in the change… but I am not sure if the explosion is correct...

                In the past.. it looked like my normal_tcp & udp Aliases... as you see the voip alias has the ip's now.. but is this the correct syntax?

                User Aliases

                normal_tcp = "{ 80 443 3389 4447 993 587 53 22 5900 1723 5999 20:21 43 873 161 9996 3074 6112 3724 1119 5354 554 8554 }"
                normal_udp = "{ 53 123 22 161 9996 88 3074 3724 554 8554 }"
                table <voip>{  192.168.1.11  192.168.1.12 }
                voip = "<voip>"</voip></voip>

                1 Reply Last reply Reply Quote 0
                • E
                  eri--
                  last edited by

                  It is correct do not worry.

                  1 Reply Last reply Reply Quote 0
                  • D
                    dusan
                    last edited by

                    After upgrading to Mar 19 14:38:08, aliases gone.

                    I observe this from pftop's Packet Counters. Every policy-based routing rule with aliased destination IP is now ineffective – the rule's packet counter shows constantly zero.

                    1 Reply Last reply Reply Quote 0
                    • E
                      eri--
                      last edited by

                      the above should fix it. apply that patch and it should be ok.

                      1 Reply Last reply Reply Quote 0
                      • D
                        dusan
                        last edited by

                        Confirmed. The Fri Mar 19 23:39:43 EDT snapshot returned it to normale.

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