Multiple IPv6 Prefix Delegation over AT&T Residential Gateway for pfSense 2.4.5
-
@fox-hound Is System>Advanced>Networking>IPv6Options>AllowIPv6 checked?
Does the same traceroute succeed from the BGW's Diagnostics>Troubleshoot>TestInternetAccess dialogue?
-
@marcg Yes it is checked. Traceroute only succeeds from WAN, not from the LAN interface
-
Just double checked the WAN interface for pfSense. It looks like DHCPv6 gave the AT&T router's link-local IPv6 address as the gateway on WAN?
-
@fox-hound I also see the BGW320's LAN-side LLA as the default v6 route on pfSense+ 23.09. The BGW320 is running 4.25.4. v6 is working for me.
-
@marcg Looks like I'm having an issue with the RG.
Checked the logs and my ICMPv6 packets are showing up with the reason: "Policy (filtersets, etc.)".
I had disabled packet filtering and the firewall on the RG, so I'm not sure what is happening.
-
@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.
-
@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!
-
@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.
-
@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?
-
@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.
-
@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 { }; -
A AndyRH referenced this topic on
-
O OffstageRoller referenced this topic on
-
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.
-
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.
-
@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 Subnetsis 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.
ULAs can be used for addresses where you need predictable prefix and (optionally) host parts, and want rule granularity beyond the prefix level.
-
@marcg Thank you for the tip. When I get some free time, I will check out the auto generated interface addresses prefix's.