@johnymarconi You had mentioned it worked until you got new hardware. I was referring to with the old vs new configuration. That is when it worked with when it didn't.

@GaZaai I’ve managed 4 days and IPv6 is still working and I’m getting 19/20 on the readiness test, I ticked not to release the PD on advanced networking, Vodafone have assigned me a static IPv4 and I upgraded to 25.03 using the new PPPoE backend. A few changes so not 100% on what was the fix but I survive reboots now, thanks for your help.

Unfortunately, it does not work for me on 25.03-BETA. The setting has not changed behaviour - i have tried a reboot after adding the setting into system->advanced>system tunables.

I did try this setting weeks ago, but since it made no difference I disgarded it.

I still need to add the static NDP entry, even with this setting.

I wonder if this setting is no longer working on 25.03-BETA. However, that NDP entry should not be going stale for 24 hours anyway and so something still isn't right. It's responding to NS, so why isn't the NDP entry updating every minute whenever they are responded to?

There is something additional I've spotted with the NA from the ISP, the source IP is GUA but the target address is link-local. I don't mean destination ip, I do mean target address within the ICMPv6 payload - before the (rte, sol) below:

4 13:45:21.68 2a02:fb8::32 fe80::1c1e:54ff:fe8a:705 ICMPv6 82 Neighbor Advertisement fe80::4a5a:dff:fe5a:f2b7 (rtr, sol)

The NDP table is being updated with the target address, but it does not update the source ip into the NDP table. That might be correct behaviour, but if so then what is updating the source ip entry in the NDP table after 24 hours (for the situation it does).

I have also seen the situation with where the NDP entry was stale for 24 hours and strangely was updated, which kept it working and when using my previous tricks to get it to work. However, it was not consistent after every reboot and connectiviy was still unreliable.

I still beleive we are walking around some other root cause here, possibly two issues.

I do admit the spec is ambiguious and this is not prohibited within the spec, but this implementation is a good example of exactly not what the spec intended. However, it should still be working.

We should not be seeing the first hop GUA going stale for 24 hours anyway.

@Laxarus

Sometimes the problems with Windows are because it's Windows. I have no experience with HAproxy.

@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!

Use hurricane electric tunnel broker service.

https://docs.netgate.com/pfsense/en/latest/recipes/ipv6-tunnel-broker.html

@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.

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.