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

    New snapshot creates pf rule that ignores default deny ipv6 for LAN

    Scheduled Pinned Locked Moved 2.1 Snapshot Feedback and Problems - RETIRED
    13 Posts 5 Posters 3.5k 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.
    • jimpJ
      jimp Rebel Alliance Developer Netgate
      last edited by

      Those rules do not have 'quick' set. You can make your own to block whatever traffic you don't want.

      The rules as they are have the intended "automatic" feel to them that most people expect. It would be nicer to have them show up in the ruleset like the existing LAN to any default rule, but maybe we can work on that for 2.2.

      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
      • R
        razzfazz
        last edited by

        It would definitely be nice if these rules at least showed up in the web interface; as it is, without looking under the hood, it's not obvious at all that the firewall is wide open for externally initiated IPv6 traffic by default. I'm not sure I'd agree that this is a behavior that most people would actually expect; I most certainly didn't.

        1 Reply Last reply Reply Quote 0
        • A
          athurdent
          last edited by

          +1
          I don't think the average user should expect this behaviour. I have been surfing the web fine via IPv6 without letting any externally initiated traffic in and I think surfing is what the average user would do. OK, IIRC one has to let ICMPv6 unreach, paramprob and toobig initiated from WAN to LAN to be sure not to break protocols. I have not looked into IPv6 active FTP though. If that is still a problem, then the FTP helper would need to be expanded if it isn't already.
          But other than that, I would not let anything initiated from the outside into LAN, especially not without a proper warning to the user.

          1 Reply Last reply Reply Quote 0
          • D
            doktornotor Banned
            last edited by

            I don't understand the idea behind this either… Allow ICMPv6 traffic on WAN, not "any". Completely unexpected behaviour.

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

              I believe originally the logic there was done to allow for a chain of routers doing delegation. For example, if you upstream DHCPv6 gave you a /48 or /56 then yours in turn would be setup to delegate its own set of prefixes back to things behind it and open traffic to them. So it was more to act as an intermediate router than to sit in front of clients.

              That could probably be revisited, only the LAN side rule is strictly necessary there.

              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
              • A
                athurdent
                last edited by

                Well I think nowadays there's quite a growing amount of clients sitting behind IA-PD.
                And even if I were to use pfSense as a device doing delegation in a chain, I would still think that I needed to write my own rules for the delegated nets, because pfSense is mainly a firewall, not just a router and thus in my opinion should be secure by default…

                1 Reply Last reply Reply Quote 0
                • R
                  razzfazz
                  last edited by

                  @jimp:

                  That could probably be revisited, only the LAN side rule is strictly necessary there.

                  Given that an explicit pass rule is required to let IPv4 traffic in on the LAN side, I think it would be more consistent to require the same for IPv6 traffic as well.

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

                    True, but there is also an expectation that it will pass out "out of the box" there. I suppose it should probably just be a default allow out IPv6 rule in the GUI like the default LAN rule though, no matter what. (For a fresh install)

                    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
                    • jimpJ
                      jimp Rebel Alliance Developer Netgate
                      last edited by

                      OK I confirmed that adding a rule to pass IPv6 from LAN subnet to any does pick up the correct delegated prefix subnet, so those rules really don't need to exist. I just pushed a commit to take them out.

                      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
                      • D
                        doktornotor Banned
                        last edited by

                        @jimp:

                        OK I confirmed that adding a rule to pass IPv6 from LAN subnet to any does pick up the correct delegated prefix subnet, so those rules really don't need to exist. I just pushed a commit to take them out.

                        Cool, thanks. 8)

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