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

    Bridge interface doesn't have a linklocal ipv6 address

    Scheduled Pinned Locked Moved IPv6
    10 Posts 5 Posters 3.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.
    • E
      eevee
      last edited by

      Reported before here, but apparently never fixed: http://forum.pfsense.org/index.php/topic,64175.0.html

      I'm running stock 2.1 on a Soekris net6501 to make a home router.  I bridged the wifi and three ethernet ports to make my LAN, then tried applying my HE ipv6 tunnel.  This sort of worked, some of the time, for some machines…  but others would just never get a v6 address with any combination of settings on either end.

      Per the older thread, turns out the problem was that the bridge interface never had a linklocal address.  radvd even complained about it on startup:

      radvd[86266]: no linklocal address configured for bridge0
      

      And on (I assume) every multicast packet it received, in the routing logs:

      radvd[86266]: received icmpv6 RA packet with non-linklocal source address from [LAN address]
      

      Manually setting a linklocal IP with ifconfig worked.


      While I'm at it, I did have one other snag that's perhaps worth addressing: there's no default rule allowing fe80::/64 to ff00::/8, so all multicast traffic was blocked, which made RA kind of not work at all.  Only figured this out by stumbling upon some suspicious-looking firewall logs.

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

        While there is no blanket rule that allows all multicast traffic to pass by default, there are default rules that specifically allow RAs and other multicast traffic required for IPv6 to pass:

        
        # Allow only bare essential icmpv6 packets (NS, NA, and RA, echoreq, echorep)
        pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {129,133,134,135,136} keep state
        pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {129,133,134,135,136} keep state
        pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {128,133,134,135,136} keep state
        pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type {128,133,134,135,136} keep state
        pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {128,133,134,135,136} keep state
        [...]
        # We need inet6 icmp for stateless autoconfig and dhcpv6
        pass quick on $LAN inet6 proto udp from fe80::/10 to fe80::/10 port = 546 label "allow access to DHCPv6 server"
        pass quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 546 label "allow access to DHCPv6 server"
        pass quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 547 label "allow access to DHCPv6 server"
        pass quick on $LAN inet6 proto udp from ff02::/16 to fe80::/10 port = 547 label "allow access to DHCPv6 server"
        pass in quick on $LAN inet6 proto udp from fe80::/10 to [LAN address] port = 546 label "allow access to DHCPv6 server"
        pass out quick on $LAN inet6 proto udp from [LAN address] port = 547 to fe80::/10 label "allow access to DHCPv6 server"
        
        
        1 Reply Last reply Reply Quote 0
        • E
          eevee
          last edited by

          Hm.  I didn't end up with any of those rules  :)  Possibly because I set up the router with IPv4 and then turned on IPv6 later?

          Incidentally (assuming I trust my LAN), is there any reason not to allow all traffic from fe80::/10 to fe80::/10?  I keep finding oddball things getting blocked, like Windows's use of UDP 1900 for some sort of discovery.

          Re the original problem: I've also twice now forgotten that the bridge interface needs a link-local address after a reboot and been very confused about why v6 is broken.  Whoops.

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

            Note that these wouldn't show up in the "rules" page; you'll have to SSH in to see them.

            As far as other random multicast traffic is concerned, it's just best practice to only pass what's actually needed. Easy enough to add rules if the log entries bother you.

            1 Reply Last reply Reply Quote 0
            • S
              sgw
              last edited by

              I am on latest 2.3.1_1 and added a Wifi_LAN-bridge today. I also don't see the mentioned rules via "pfctl -sr" and RA doesn't work correctly.
              What is the recommended way to get these rules set?

              cutnpaste somewhere?

              pls advise.

              2nd EDIT :: bump … nobody with a pointer?

              1 Reply Last reply Reply Quote 0
              • S
                sgw
                last edited by

                @eevee:

                Re the original problem: I've also twice now forgotten that the bridge interface needs a link-local address after a reboot and been very confused about why v6 is broken.  Whoops.

                How did you set that link-local adress? My bridge interface also misses it.
                I already added firewall rules as mentioned, still no IPv6 adresses assigned in LAN and WLAN.

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

                  There's an open bug on that.
                  https://redmine.pfsense.org/issues/4218

                  1 Reply Last reply Reply Quote 0
                  • S
                    sgw
                    last edited by

                    @cmb:

                    There's an open bug on that.
                    https://redmine.pfsense.org/issues/4218

                    Thanks for the pointer, adding those lines actually worked for me.

                    1 Reply Last reply Reply Quote 0
                    • S
                      sgw
                      last edited by

                      bump

                      It would be great to get that bug fixed while 2.3.3 is developed.
                      Right now I patch interfaces.inc every time I pull the current development snapshot  ;)

                      1 Reply Last reply Reply Quote 0
                      • BoabB
                        Boab
                        last edited by

                        Thanks, patched the file and fixed my problem in 2.3.4 - guess issue has no priority…

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