@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

@hsv I noticed problems with IPv6 too, but for me these are not general but individual to an interface. For example, because mine is virtual and I deleted a "faulty" interface, added a new one and problem was gone (new MAC address etc.). So maybe try this four your installation too, if you can.

@jbattermann I used :1::1/64 as the gateway address and the following in the RA section as I have Apple devices :- [image: 1656097296144-screenshot-2022-06-24-at-20.00.36.png]

When this used to be a problem for me, I added the 192.168.100.x IP to the dhcp ignorelist so pfSense would not accept it when offered by the ISP CPE. This definitely helped.

@jknott said in fe80::1:1 as static route for ipv6 track interface LAN? also LAN link-local no response?: There are 256 possible prefixes within that /48. You use the other prefixes for other interfaces. My mistake. That should be 65536, not 256. Better have another beer.

@bob-dig Thank you, but why the German sub-forum? In the end, I will have to try what you suggested. I was hoping to get to know, how to analyse such issues, to learn something and solve future problems by myself.

I just pushed an update to my PR #4595 that attempts to mitigate this issue. Testers wanted!

Well, your title differs from what you say in the post. While it is quite possible to resolve v4 records. i.e. A records which always return ipv4 addresses compared to AAAA records which are ipv6 records, you will never be able to ping ipv4 domains from an ipv6 network. These are two completely independent networks. A ipv4to6 nat device is needed, (or an ipv4 address) having access to both networks to be able to ping v4 This is also known as a nat64 device. Unfortunately pfsense has this set to a future release, since ipfw is deprecated.

@johnpoz While there is a cost of moving to IPv6, there is also a cost of not moving. For example if a company like Amazon doesn't support IPv6, it will become more difficult to do business in China. Another major ISP and cell carrier is Bell Canada. They don't provide IPv6 to their ADSL connected customers, but they barely provide it to their cell customers (they fail testipv6.com). This means their networks already support IPv6. A reseller that uses Bell's ADSL service, Teksavvy, manages to provide IPv6 where Bell doesn't. It appears most of the work is already done for Bell to provide IPv6 properly and to all customers. Also, years ago, the U.S. government mandated IPv6 for all public facing servers and not too long ago for all network suppliers. So, more and more, those who do not enable IPv6 look like they have their head in the sand.