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

    Router Advertisement

    Scheduled Pinned Locked Moved IPv6
    6 Posts 2 Posters 3.3k 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
      judex
      last edited by

      Hi Pros!

      My "2.1-BETA1 (amd64) built on Sat Apr 20 19:56:40 EDT 2013 FreeBSD 8.3-RELEASE-p7" pfSense runs great with HE Tunnel and /48 IPv6 Dual stack on three interfaces: LAN, DMZ, WAN

      I subnetted the 48 in two 64s for LAN and DMZ. On LAN I have RA set to Unmanaged. On DMZ I set it to Router only. So I expected rtadvd only to advertise itself on the interfaces it is assigned to, as the text on the RA page suggests.

      But what happens ist that my Windows clients on the LAN side get two default gateways with their link-local addresses. Should't the LAN clients only see the LAN RA gateway?

      It is a minor problem as I can turn of RA on DMZ - then the LAN clients only see the correct LAN gateway and configure that.

      Any hints?

      Alex

      2.1-RELEASE (amd64)
      built on Wed Sep 11 18:17:48 EDT 2013
      FreeBSD 8.3-RELEASE-p11

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

        "Unmanaged" and "router only" both send RAs. That sounds like the expected result if you have LAN and DMZ plugged into the same broadcast domain. Which you shouldn't if you want a proper DMZ.

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

          Well, two different 64 ipv6 nets on DMZ and LAN are not exactly the same broadcast domain, are they?
          Why should the RA from the DMZ net advertise itself on LAN? That ist not what is described on the RA php page.

          2.1-RELEASE (amd64)
          built on Wed Sep 11 18:17:48 EDT 2013
          FreeBSD 8.3-RELEASE-p11

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

            It shouldn't be on both networks unless both NICs are plugged into the same switch/broadcast domain, or you have them bridged. Or the hosts involved have a connection to both networks on them. It sounds like one of those circumstances is likely the case, given there are a lot of networks with that exact circumstance that don't show those symptoms.

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

              Thx for your thoughts!

              That was my first suspect: pfsense runs in a virtual machine on interfaces that are bridged in the KVM host. On the host I block all traffic from the bridges with iptables, so ICMPv6 shouldn't get over the host systems bridge interface.

              I tested the block with "ping6 -I vtnet2 -n ff02::1" and did not get answers (where vtnet2 ist the DMZ interface in the pfsense KVM guest machine). Forwarding is also turned off in the KVM host (Debian).

              Oviousely I miss something.

              Alex

              2.1-RELEASE (amd64)
              built on Wed Sep 11 18:17:48 EDT 2013
              FreeBSD 8.3-RELEASE-p11

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

                Phew, the solution was hard to find. I have a MAC based VLAN membership configured on a switch port for the DMZ VLAN. This MAC based VLANs are built with untagged member ports. The advertisement was sent to ff02::1 over this port and reached all clients behind not only the VLAN members.

                Alex

                2.1-RELEASE (amd64)
                built on Wed Sep 11 18:17:48 EDT 2013
                FreeBSD 8.3-RELEASE-p11

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