So, I found a GUI "bug". I had correctly set the prefix ID's in the "Tracked Interface" for each VLAN, but at the RA page, I mistakenly reinserted the prefix ID in the fields that are for static (full, not delegated) prefixes. Removed the static prefixes and everything now works. GUI should not let you enter static prefixes on a tracked interface, aside from fc00 or fd. And if it does, it should check if they are correct. One of the prefixes was ::1/64.

@noviceiii Here's an example of what I'm looking for in the captures. This is just part of one packet of 8. [image: 1660173104939-5494ae04-4151-4fb1-a332-0dd7a0ea02a9-image.png]

@cyth I did a clean installation of pFSense out of the box provided IPV6, without changing any settings. Looks like they just started rolling dual stack so it will be some issues until they figure it out and finish the implementation. So far my pFSense is working, no issues with internet IPV6 traffic. From Verizon Automatic provide to pFSense address size. Then I upgraded to pFSense plus, no issues working our of the box. I spend a lot of time tried to figure it out, and looks like all this time was Verizon implementation issues. I found out I started getting IPV6 because, some of my devices stop working, the reason was because those devices tried to communicate only using IPV6, they were giving priority over IPv4.

@zennb1 Clients rely on router advertisements to learn the LAN prefix and they append the suffix to it. Run Packet Capture, filtering on icmpv6, to see if you have them. You could also run Wireshark on a computer to do the same thing.

@mikev7896 My problem is that my ISP sends multiple /64 IP prefixes with its RAs although DHCPV6 is used Pfsense than takes these Prefixes and configures multiple wan addresses. The problem is now that not all of these addresses work My idea was then to switch off the Address Auto configuration on WAN, but I don't know exactly how I can do that

@steveits Hey there and thanks for your reply. That is what I thought. So, there must have been some rule responsible for this issue. Since the Screenshots of wan and lan did not show any such rule, I figured there must have been other rules... Just uninstalling pfblockerng solving the problem seems strange otherwise. Just trying to understand this issue.

@vortex21 Hi, I reconfigured my network yesterday to eliminate the pfSense WAN connection being on a VLAN on the external network port. The WAN interface is now the physical interface card my problem of IPv6 WAN Gateway monitoring reporting 100% loss no longer occurs. So it appears the problem was related to the use of a VLAN.

Oof, maybe I am just an idiot. I finally looked at /var/etc/radvd.conf: interface igc0 { AdvSendAdvert on; MinRtrAdvInterval 200; MaxRtrAdvInterval 600; AdvDefaultLifetime 1800; AdvLinkMTU 1500; AdvDefaultPreference medium; AdvManagedFlag on; AdvOtherConfigFlag on; prefix [COMCAST-PREFIX]::/64 { DeprecatePrefix on; AdvOnLink on; AdvAutonomous on; AdvValidLifetime 86400; AdvPreferredLifetime 14400; }; prefix fd0f:f5b9:d3f9:3068::/64 { DeprecatePrefix on; AdvOnLink on; AdvAutonomous on; }; route ::/0 { AdvRoutePreference medium; RemoveRoute on; }; RDNSS fd0f:f5b9:d3f9:3068::1 { AdvRDNSSLifetime 1800; }; DNSSL [DOMAIN] { AdvDNSSLLifetime 1800; }; Sorry for wasting your time! It looks like pfsense's configuration "does the right thing" in radvd.

@jimp I get it, sorry for the misunderstanding

@dvonhand Once again, you need packet captures, to see what's happening.

@jknott Yeah after doing a bunch of research and reading some IPv6 RFC's I decided to just use unmanaged. Everything is working good and I got to turn off the DHCPv6 server. One less thing I have to deal with.

@bob-dig said in After IPv6 prefix change no IPv6 connectivity on Windows host: Maybe the default lease times for IPv6 should be drastically shortened on any interface which uses "track". Another way to tackle that would be to use NPt I guess. So it would be great for that, if pfSense allows to use Track Interface in the NPt options directly instead of only using it for "physical" interfaces. [image: 1658221444096-capture.png]

@skilledinept If you want to connect to the firewall with a VPN, etc., you can use another interface address, such as the LAN. Perhaps if you mentioned your ISP, someone else might be able to help.

Update: I did some more reading on these forums and found this discussion from a few months ago that contained the solution. I need to specify the whole prefix delegation range allocated to me by the ISP: [image: 1657208348501-screenshot_dhcpv6_working.png] As far as I know it's not possible to automatically update this prefix delegation range if the ISP decides to change it; I'll have to update it manually if that ever happens. Please correct me if this statement is wrong... Consider this question answered. Will leave the post up in the hopes that it will serve as a template / tutorial for others trying to do the same thing in the future.

@jknott I didn't upgrade because of the issues with intel nics and the at&t fiber bypass on 2.6.x Apparently, fixed drivers aren't going to be provided till 2.7 so I'm holding off till then. Having my primary connection working is more important then having the latest version.

If some sites work, but others don't, it's not likely a pfSense issue. What comes to mind is the site has an IPv6 address, but it's not working properly. However, in that case, it should time out and switch to IPv4. Can you do a packet capture of what happens when those sites fail?

@junicast To whom it may concern. We just migrated to different hardware and the original problem with reloading firewall rules is now resolved big relief. Actually it happened again. I suspect the Intel X170 are just bad and the update to pfSense 2.6 triggers this problem. Jun 30 10:24:05 fw3-rx kernel: ixl0: Interface stopped DISTRIBUTING, possible flapping The other problem persists. Neighbor discovery fails and the reason is that the primary firewall uses its Global Unicast address in the source field instead of the Link Local address. That was not the reason. We observed other occurences of NDP using UGA as source and those worked. At first I though some NAT rules might be the reason for that but after deactivation the problem persists. I checked that all interfaces have a Link Local address assigned so that also isn't the reason. Does someone have an idea under what circumstances this might happen? Edit: We contacted Netgate about it. They think this might be an actual FreeBSD bug. They do now have a solution, yet. [image: 1656577384667-d97a8679-c393-4c06-ad30-bbd11056ccf7-image.png]

@jimp Working fine here too