@Gertjan said in Unbound/DNS resolver with IPv6 unreliable finally solved: Isn't that a 'syntax error' ? Yes, typo. Post edited. Thanks for pointing out.

Hi @Gertjan, Thanks for send your example. Today I got back to working on the IPv6 deployment in my network and decided to take a different approach, since multicast packets really weren’t reaching pfSense—something quite odd. So I started troubleshooting at Layer 2 and finally found the issue. Since my pfSense runs virtualized with libvirt, I began digging into potential multicast issues related to libvirt’s network interfaces. I’m using macvtap with virtio to provide smoother network passthrough to the VM. On a forum, someone mentioned a parameter (trustGuestRxFilters) that needs to be enabled on the interface to allow multicast traffic. By default, it’s disabled. I checked the documentation, and it turned out to be true. Once I enabled the parameter, DHCPv6 started working immediately. <interface type="direct" trustGuestRxFilters="yes"> <mac address="52:54:..."/> <source dev="fw_lan" mode="bridge"/> <target dev="macvtap3"/> <model type="virtio"/> <alias name="net1"/> <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> </interface> @Gertjan, @patient0, and @JKnott – thank you all for taking the time to help us work through this issue. I'm really grateful to be part of such an active community, full of helpful and kind people! I hope this experience proves helpful to others who might run into the same issue. All the best!

@Bob-Dig ah I thought that setting it enabled meant all incoming IPV6 WAN traffic would be allowed in. If I'm enable is default WAN inbound still block for IPv6?

Here is update: I requested an IPv6 prefix from the second ISP, who was able to split it and set up routing to the related WAN IP addresses. I then contacted the first ISP again and they agreed to do the same. Problem solved, I can still run the routers independently.

@patient0 Haha, yeah, but look how bad my IPv6 is! Going to leave it with IPv4 preferred, but thank you very much for taking the time to help. Those were great suggestions, and in the end this issue just highlighted how bad my ISP's IPv6 is. Hyperoptic, get your IPv6 house in order!

@F022Y said in Lit Fibre (UK) IPv6 stopped after powercut: First step was to check the internet was actually down Note these on an post-it : ipconfig /all ipconfig /renew ipconfig /renew6 The second renews the IPv4 lease. If it times out : DHCP4 isn't running ? The third : IPv6 lease gets renewed. If error, DHCOPv6 server isn't running ? (or no more prefix for that LAN, etc) Be ware : IPv6 is default, so if "ping www.google.com" will use IPv6. Force it to use IPv4 by entering : ping -4 www.google.com or the other way around : ping -6 www.google.com @F022Y said in Lit Fibre (UK) IPv6 stopped after powercut: only IPv6 traffic worked and IPv4 was a no go Welcome into 2025, Yes, DHCP4v should be stable right these days. If any doubts, use the DHCPv4 server (on pfSense) that is known to be good : use ISC. You are using kea right now. [image: 1742540498341-34ba9510-17e6-4205-8b77-3379a1a610e3-image.png] kea works fine, I'm using it for month now, but I have the more recent 24.11 (and 25.03 now). IMHO : If you have to offer your wife a depreciated (but 3 decades proven) DHCPv4 server, or a 'beta' (implementation) Kea, go for the first - or get a lawyer ^^

@Bob-Dig That's very Interesting, oddly though, the client with 0 issues is also the client with the extra stale ipv6 addresses. I found some info on some MS forms that suggests Windows has an issue when the NIC is using both IPV4 DHCP and IPV6 RA at the same time. i.e. other have seen similar DNS weirdness. On the broken system I just tried disabling IVP4 TCP/IP and after rebooting that same box now receives an IPV6 DNS Server. If I then re-enable TCP/IPV4 on the nic, that same system wipes out the DNS servers and replaces with only an IPV4 value. So this is really starting to feel like a pure MS bug, I don't see how the above could be influenced by PFSense.

Deleting this thread and starting over, fixed my issue but found a new one.

@timg_11 The images are available on the Wayback machine at archive.org. I just did the same thing as you, but I'm trying to route IPv6 on Linux

I opened a ticket with my host on this. Since that fe80:1::4aa9:8aff:fe18:7bf9 isn't mine and appears to be coming from my host I'm guessing there is a routing issue for my /64. IMHO it looks like something is stealing my route like it's double routed or something. They've been "researching" for the past 2 days.

@patrickdickey52761 said in Verizon 5G Home Internet: So let me ask this. Is there an easy way to allow IPv6 traffic through my WAN interface in such a way that all devices on the LAN side can get their addresses? You could configure pfSense as just a firewall, without routing. A friend of mine just did that with OPNsense. This way you'll have a single /64 to work with on your LAN.

@artafinde said in IPv6 connectivity NAT: DHCP6C logs A WAN interface, igb0, became active, so dhcp6c starts doing its work : The first part, where dhcp6c has process ID 867, goes well up until something/someone pulls the plug : dhcp6c[867]: transmit failed: Network is down So, djcp6c starts again : .... process ID is now 26116. It also ... vanishes. New process again : dhcp6c[26428]: transmit failed: Network is down but 26428 manages to get everything right : an IPv6, a prefix Reaching this phrase : got an expected reply, sleeping means all is well. I'm not saying that these multiple restarts with 7 second are not normal, maybe you can set up an initial "10 seconds or so" hold off, see the dhcp4 parameters ? (not sure if the dhcp6 process has the same process option, you'll need to see the man ?) I've this : [image: 1739862805019-0c2adff7-6ab2-4b7e-973d-ef6f810bdc03-image.png] = nothing checked as you can see and it works fine for me.

I'm using pfSense + 24.11 . The menu/settings structure is not exactly the same. I believe I found the equivalents, and tried to apply them. I just could not get IPv6 to work on my LAN. I even did a full factory reset of pfSense and started from scratch, following instructions in this thread. It's a no go. I'm using a Comcast XB8 in bridge mode, but don't think the modem makes any difference. IPv4 works great, including inbound for my Wireguard VPN.

working now New GUAs

https://redmine.pfsense.org/issues/15808 Should be in the next release 2.8/25.03 I think NAT64 might also come in that release. I'm hoping for custom dhcp options in KEA, but the old dhcp is a fallback. Then i need to wait for CLAT in Windows, which was talked about in a blog post last year, radio silence sinse then from MS

@Gertjan the alexas can dos my pihole all they want ;) that has zero to do with the cameras talking to the nvr, which is on an isolated network behind the nvr. And they could cut the power to the house as well. The nvr is on a ups and the cameras are poe - so while it won't last days should be able to get good 30 minutes or so of run time. Alexas in the landfill, what you have me do touch a light switch like a savage? ;)

@Bob-Dig That looks like it worked! Is there a limitation I should be aware of with how quickly those rules will update? I just don't want to leave an open hole in my firewall whenever my ISP drops the ball.