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

    Multiple IPv6 Prefix Delegation over AT&T Residential Gateway for pfSense 2.4.5

    IPv6
    30
    147
    60.9k
    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.
    • M
      marcg @fox hound
      last edited by marcg

      @fox-hound I see those in the logs as well with the BGW320's packet filters disabled. Maybe because of the following settings.

      FWIW, I have a suspicion that the BGW sometimes reverses source and destination addresses its state table display and maybe firewall logs. I'll have flows that I know are initiated outwards from the LAN and are listed in the pfSense state table as such, but show as initiated inwards on the BGW. I look at the BGW's logs with a grain of salt. More details here.

      c7b3c02b-7fbf-43e6-afbc-b5ddd11c9ad1-image.png

      F 1 Reply Last reply Reply Quote 0
      • F
        fox hound @marcg
        last edited by

        @marcg Those settings (and packet filter) were all showing as disabled. Looks like I resolved some weird glitch on the RG.

        I re-enabled the packet filter and advanced firewall settings in the RG, disabled them again, then rebooted by RG and pfSense. Very odd, IPv6 is now working. Thank you!

        1 Reply Last reply Reply Quote 1
        • M
          marcg @fox hound
          last edited by marcg

          @fox-hound said in Multiple IPv6 Prefix Delegation over AT&T Residential Gateway for pfSense 2.4.5:

          @marcg Those settings (and packet filter) were all showing as disabled. Looks like I resolved some weird glitch on the RG.

          I re-enabled the packet filter and advanced firewall settings in the RG, disabled them again, then rebooted by RG and pfSense. Very odd, IPv6 is now working. Thank you!

          Great. I had a temporary glitch with IP Passthrough after upgrading to 23.09. Resolved on its own after a couple of hours but I wonder whether you encountered something related.

          1 Reply Last reply Reply Quote 0
          • C
            czlong @ttmcmurry
            last edited by

            @ttmcmurry I've read and studied your work on this. Did you leave out the shebang (#!/bin/sh) on purpose or is it just not necessary?

            T 1 Reply Last reply Reply Quote 0
            • T
              ttmcmurry @czlong
              last edited by

              @czlong - I've come a long way since May of 2020 when this post was made, but not far enough to answer your question with authority. Unfortunately, I'm not much of a linux scripter. I do my best to the extent that if the thing I'm working on accomplishes the goal, I accept the results until they no longer work - or if the community comes up with a better way to do it, and utilize that solution instead. 😊

              C 1 Reply Last reply Reply Quote 1
              • C
                czlong @ttmcmurry
                last edited by

                @ttmcmurry btw, I finally got dhcp6 working pfsense+ (23.09-RELEASE) on my home network. My architecture - ATT modem (Pace 5268) in DMZ Plus mode, Netgate 1100, using upgraded Kea DHCP, GS110TPV3 poe switch, WAN, LAN + 4 VLANS (Admin, Guest, IoT, IPCam), 3 wireless APs. I found out the hard way, reading error logs, that the Guest WAP was not ipv6 enable so it kept failing for everything. Once I remove PD request for that interface everything worked (of course no ipv6 for the Guest interface I'll upgrade the device later). This works and thanks for all of the ground work you've done on this.

                interface mvneta0.4090 {
                send rapid-commit;
                send ia-na 0;
                send ia-pd 0;
                send ia-pd 1;
                send ia-pd 2;
                send ia-pd 3;
                send ia-pd 4;
                send ia-pd 5;
                send ia-pd 6;
                send ia-pd 7;
                request domain-name-servers;
                request domain-name;
                #script "/var/etc/dhcp6c_wan_dhcp6withoutra_script.sh";
                script "/var/etc/dhcp6c_wan_script.sh";
                };

                id-assoc na 0 { };
                id-assoc pd 0 {
                prefix-interface mvneta0.4091 {
                sla-id 0;
                sla-len 0;
                };
                };
                id-assoc pd 1 {
                prefix-interface mvneta0.20 {
                sla-id 0;
                sla-len 0;
                };
                };
                id-assoc pd 2 { };
                id-assoc pd 3 {
                prefix-interface mvneta0.40 {
                sla-id 0;
                sla-len 0;
                };
                };
                id-assoc pd 4 { };
                id-assoc pd 5 { };
                id-assoc pd 6 { };
                id-assoc pd 7 { };

                1 Reply Last reply Reply Quote 0
                • AndyRHA AndyRH referenced this topic on
                • O OffstageRoller referenced this topic on
                • F
                  fox hound
                  last edited by fox hound

                  After a fresh install and restore of configurations (virtualized pfSense), I noticed that my WAN was receiving the IPv6 address, but not the LAN. Couldn't ping any IPv6 address.

                  Once I changed my WAN and LAN interface config "Speed and Duplex" from Default to Autoselect, everything worked.

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

                    Working pfSense 24.03 and have a Protectli FW4C and a older FW4B. The FW4C is my production router. I decided to configure the FW4B as a cold swap backup in case I am out of town and the wife had to replace.

                    As I was configuring FW4B this weekend for a "cold backup" device that I noticed that all my PD indexes scrambled the order of my IPv6 networks. I had to work though the config file and PD index one by one to re-assign the network to the right IPv6 address I originally configured. Very painful process.

                    Then when I put the primary router back on the network again the order of IPv6 addresses assigned to PD index changed again.

                    Is there any rhyme or reason for how AT&T assigns PD networks to the index of 0-7? I know I am going to get his with this again if I really had to do a router swap.

                    M 1 Reply Last reply Reply Quote 0
                    • M
                      marcg @ronv42
                      last edited by marcg

                      @ronv42 I've also noticed prefixes being assigned differently to the same IA_PD across different routers (pfSense vs. Ubiquiti in my case).

                      If your v6 firewall rules are blocking/allowing GUAs on a prefix/VLAN basis rather than on a host basis, you might write them in terms of the auto-generated subnets alias which tracks prefixes from the BGW. In the example below, E1V15 Subnets is the auto-generated alias on interface igc1.15, which is the subinterface for dual-stacked VLAN 15 and receives a v6 GUA prefix from the BGW. The rule works regardless of the delegated prefix.

                      1d0feb01-0d95-42e2-a3ad-9bb8351379c0-image.png

                      ULAs can be used for addresses where you need predictable prefix and (optionally) host parts, and want rule granularity beyond the prefix level.

                      R 1 Reply Last reply Reply Quote 0
                      • R
                        ronv42 @marcg
                        last edited by

                        @marcg Thank you for the tip. When I get some free time, I will check out the auto generated interface addresses prefix's.

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