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.

@joe90 If it is assigning an address from with your prefix, then that address will start with your /56 prefix. I don't have any experience with IPv6 on PPPoE or with OpenWRT, so I don't know what else to check. However, you don't need a WAN GUA. If you want to access pfSense from elsewhere, you can use the LAN interface address.

@jknott I see, i need to take a closer look to the virtual IP settings

@aeminkocal Is the VM set up as a bridge or NAT connection? If NAT, the IPv4 address will be in a different subnet than the LAN and IPv6 won't work. You need to bridge the interface. Also, it might help to mention which VM you're using.

After I reset pfSense, and did a new setup, the issue still remain. I can't connect to archlinux.org via IPv6. @johnpoz said in Not able to connect to some website: I would suggest he moves his lan back to 1500, and then get with his ISP for the proper setup for his wan connection.. A common pppoe mss clamp size is like 1452.. But for optimal working with his ISP he should contact them for proper setup. I agree, I should consult my ISP for help. I left MTU and MSS default. Will it related to PMTUD no working? The last result might be using pfSense in transparent mode. I've never tested it yet. Another issue is ICMP req always failed (tested using ipv6-test.com), even I allow it on WAN interface. This didn't happen on my last configuration, which is pretty much the same as this one except I left DHPCv6 enable. I think I disable DHCPv6 last time, MyPC use RDNSS instead. I'm scratching my head off.

I just now found a small config in the bridge advanced setting: [image: 1652816053276-screenshot-from-2022-05-17-21-33-59.png] My local hosts now have an autoconfigured ip in the LAN-range (At least, I assume it's auto-configured, since the dhcp6 server isn't working still) Routing is still all broken though, so it's only a small boon (And probably isn't helping the hosts in question at all, having to realize ipv6 isn't an option after timeout) Still - Wanted to keep you guys posted, if this could trigger something

Attached pcaps: VM2.pcapng VM1.pcapng