Navigation

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

    Default deny IPv6 (FE80 –> FF02) on laggX

    Firewalling
    4
    11
    3331
    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.
    • R
      rsaanon last edited by

      Hello everyone!

      – I have a couple of VLANs (i.e.: vlan1, vlan2) that are associated with the LAGG (as a parent interface).
      -- I then have WAN + 2 LAN interfaces that correspond to the respective network port (eg: vlan1 on lagg0, vlan2 on lagg0)
      -- IPv6 is ONLY enabled for the WAN. That is, the two LAN side interfaces do not have IPv6 enabled ("IPv6 Configuration set to None")

      However, in the firewall logs, I see bunch of DENY link-local  to multi-cast entries like:
        Interface  Source          Destination  Proto
        lagg0      fe80::6abd..  ff02::1:2        UDP

      Why am I seeing the above firewall log entry when IPv6 has not been enabled for any of the interfaces?

      Thanks!

      1 Reply Last reply Reply Quote 0
      • johnpoz
        johnpoz LAYER 8 Global Moderator last edited by

        Because you have it set to log everything it blocks, it blocks that so it logs it..

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

          Thanks for responding.

          The question, though, was why is the IPv6 traffic originating when all the defined lan interfaces on the lagg has IPv6 disabled.

          1 Reply Last reply Reply Quote 0
          • johnpoz
            johnpoz LAYER 8 Global Moderator last edited by

            its not originating on pfsense - you have some client sending out that data.. If you don't want pfsense to see it block the ipv6 multicast at your switch or turn off ipv6 on the client sending it.

            Or disable the log all default blocks and create your own block rule with logging setup that only blocks ipv4 and logs that, etc.

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

              Thanks, once again!

              I understand that the IPv6 traffic is not originating at the pfSense box; however, since none of the pfSense defined interface has IPv6 enabled, how is the interface able to receive any IPv6 messages?  One interesting observation is that:–> The firewall log entry shows the lagg0 as the interface that is getting the IPv6 messages.

              1 Reply Last reply Reply Quote 0
              • C
                cmb last edited by

                Exactly what johnpoz said, it's multicast IPv6 which will reach the system from your switch regardless of whether v6 is enabled where something on your network's sending it.

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

                  Perplexed!!

                  My firewall logs are getting stormed by the "default deny ipv6 rule" (please see attached image).  Also, when I try to create an "Easy Rule" to Pass the traffic, I get a html information page (see attached pfcapture2.jpg image).

                  The issue is that I am not able to perform any kind of remediation (ie: create pass rule etc.), because the source interface in the firewall log actually shows up as "lagg" an not one of real interfaces that I can perform rules on.

                  Any help greatly appreciated!




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

                    Hello,

                    I had the same type of issue with ipv6 getting logged. Some older post on here show issues where enabling IPV6 and then adding a floating rule which DROPPED all IPv6 from ANY with out logging sorted it for me. I dont use LAGG, am new to the forum, and am not sure if this is the best solution for you. However, it stopped my logs from being spammed which is what I was looking for.

                    1 Reply Last reply Reply Quote 0
                    • C
                      cmb last edited by

                      @dmunk:

                      I had the same type of issue with ipv6 getting logged. Some older post on here show issues where enabling IPV6 and then adding a floating rule which DROPPED all IPv6 from ANY with out logging sorted it for me. I dont use LAGG, am new to the forum, and am not sure if this is the best solution for you. However, it stopped my logs from being spammed which is what I was looking for.

                      That'll work the same here. It's not related to the lagg, same cause and solution regardless of interface type.

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

                        The Default deny IPv6 (FE80 –> FF02) on laggX continues to plague my logs EVEN AFTER appropriate Firewall RULE has been created.

                        FIREWALL LOG ENTRY ("Default deny rule IPv6"):

                        Interface: laggX (where X = 0,1,2)
                        Source: [fe80::6abd:abff:fe0f:d7bf]:546
                        Dest:     [ff02::1:2]:547
                        Proto:    UDP
                        

                        FIREWALL RULE:

                        
                          Proto     Src   Port  Dest           Port 
                        IPv6 UDP  *     546    *               547
                        IPv6 UDP  *     *       FF02::/10    *  
                        
                        

                        Note1: Since the log shows as the "laggX" as the interface and not the actual interface, I created a floating rule that applies to ALL interface.
                        Note2: Please see the attached two screenshots of the firewall log entry and the firewall rule defined.




                        1 Reply Last reply Reply Quote 0
                        • C
                          cmb last edited by

                          You should block, not pass that traffic. And you have to enable quick.

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post

                          Products

                          • Platform Overview
                          • TNSR
                          • pfSense Plus
                          • Appliances

                          Services

                          • Training
                          • Professional Services

                          Support

                          • Subscription Plans
                          • Contact Support
                          • Product Lifecycle
                          • Documentation

                          News

                          • Media Coverage
                          • Press
                          • Events

                          Resources

                          • Blog
                          • FAQ
                          • Find a Partner
                          • Resource Library
                          • Security Information

                          Company

                          • About Us
                          • Careers
                          • Partners
                          • Contact Us
                          • Legal
                          Our Mission

                          We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                          Subscribe to our Newsletter

                          Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                          © 2021 Rubicon Communications, LLC | Privacy Policy