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

    NPT rules are not created and no error warning appears.

    IPv6
    2
    3
    627
    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.
    • F
      fabianburpf
      last edited by

      Re: Firewall rules bug?

      The NPT rule worked fine until version 2.4.3_p1. However, when updating to 2.4.4, it stops working. Reverted with a snapshot of the virtual machine and it worked, Today was updated to 2.4.4_p1 and the problem continues. Discover this error The correction made by @jimp. The manual.inc filter file has been edited and the added lines have been removed:

                          /* Do not form an invalid NPt rule.
                           * See https://redmine.pfsense.org/issues/8575 */
                          if (!is_subnetv6($srcaddr) || !is_subnetv6($dstaddr)) {
                                  continue;
                          }
      

      Everything works now and the rule appears in /tmp/rules.debug in this way:

      binat on $WAN inet6 from 2600:1fxx:xxxx:xxxx:xx::1000 to any -> 2600:1fxx:xxxx:xxxx:xx:xxxx:xxxx:xxxx
      binat on $WAN inet6 from any to 2600:1fxx:xxxx:xxxx:xx:xxxx:xxxx:xxxx -> 2600:xxxx:xxxx:xxxx:xx::1000

      Previously the rule did not appear and it appeared until 2.4.3_p1

      I do not know if there is an error in the way he has put, in the web interface, the NPT rule, but it worked. Nor would I want to edit the file by hand in each update.

      Here screenshots:

      0_1543889001323_Captura de pantalla de 2018-12-03 19-26-05.png

      0_1543889010799_Captura de pantalla de 2018-12-03 19-26-19.png

      The rule of use and use to provide ipv6 through OpenVPN and continues to work with that edition.

      https://redmine.pfsense.org/projects/pfsense/repository/revisions/29e8d025844861c12e0070ee6462339d4f4e0937/diff

      https://redmine.pfsense.org/issues/8575

      https://forum.netgate.com/topic/131924/firewall-rules-bug/5

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

        Looks like when the code just before that test processes the address it comes out without a prefix on it since it's /128, which made it fail that validation. I created an issue and pushed a fix:
        https://redmine.pfsense.org/issues/9163

        If you use any other prefix than /128 it would work as a workaround, or apply the commit that shows up on the issue above using the system patches package. It will show up in 10 minutes or so.

        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!

        F 1 Reply Last reply Reply Quote 0
        • F
          fabianburpf @jimp
          last edited by

          @jimp Thanks, this time I have edited the file /etc/inc/filter.inc as it appears here: https://redmine.pfsense.org/projects/pfsense/repository/revisions/e9446f537051c7b536d0b3fbb5ebd00c3766001a/diff?utf8=%E2%9C%93&type=sbs

          		/* Do not form an invalid NPt rule.
          		 * See https://redmine.pfsense.org/issues/8575 */
          		if (!(is_subnetv6($srcaddr) || is_ipaddrv6($srcaddr)) ||
          		    !(is_subnetv6($dstaddr) || is_ipaddrv6($dstaddr))) {
          			continue;
          		}
          

          the system patches package it seems that it is not ready yet, but with that edition by hand it works great for now and in version 2.4.5 it will be fixed.

          Putting a prefix other than 128 does not work in the environment I use, the rule is created, but it does not work as expected.

          Thank you

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