Unfortunately this issue still persists in pfsense 2.8.0. At least most European isps still hand out dynamic ipv6 prefixes to their customers which leads to the described issues with slaac.

Refer to: https://redmine.pfsense.org/issues/15746

@tchello What I can tell you is the info they gave you will not work.. They have given you a /56 that is directly attached to them - not routed to you that you can use on prefixes behind a router.

And directly attaching a /56 is borked.. They need to route the /56 to you - so that you can then break up that /56s to use on your networks behind pfsense.

There needs to be a transit network to route to you - be it a /64 or a /128 or even just link-local.. But you can not put a /56 on an interface and expect it to work.

@Superfletch I did using outbound NAT6, but I since switched to openwrt and no longer use pfSense

@BigTulsa said in Alternate gateway monitoring and IPv6:

I'll take your word for that as my knowledge of IPv6 and how it works is limited for now.

Just a suggestion, look up like the beginning of a current Cisco CCNA course. They cover IPv6 stuff in great detail before they start to get into the specific Cisco stuff. Really good way to get spun up on all the settings.

@GeorgePatches said in Applying a rule to a single client in a SLAAC only network?:

This won't solve the problem if the ISP rotates your prefix delegation on the regular (my personal experience with Verizon FIOS residential).

Very true.
If any of my LAN devices asks for DHCPv6 lease it will last, on a typical WIN11, 6 hours.
That is, that is what I see :

81557cd4-196e-4b55-adce-9077422a7604-image.png

and now it's 09h44, and I just renew the lease manually with ipconfig /renew6.

If, moment later, my upstream ISP allocated me a new prefix, the DHCP6 LAN server will get restarted with the new prefix ... but my LAN devices still use their now depreciated old prefix.
I'm not sure if other IPv6 magic exists that can warn the LAN device that 'something' has changed, and that it should force renew it's IPv6 lease.
If not, then yeah, now we have a routing issue.

Yes, a prefix can change, but shouldn't change "often". And that is an RFC standard.
For example, since my pfSense is activate on my now IPv6 ISP router, about 18 months now, my prefix didn't change.
France - country where I live - they managed to create a 'law' (privacy act stuff whatever) that an "IP" should at least change ones a year. As I have a 'pro' account, I opted out for that, so my WAN IPv4 and IPv6 (prefix) are pretty rock solid.

Constantly changes prefixes, imho, is a pure pain.
The real issue is : the (IPv6) RFCs exists. And every ISP out there interprets them somewhat differently.

@GeorgePatches said in Applying a rule to a single client in a SLAAC only network?:

The only solution to this problem that I've come up with is to setup dynamic DNS on the client I want to make a rule for, create an alias for said DDNS entry, and then use said alias in a firewall rule.

That is exactly what I do 😊
But I'm not using the classic "Services > Dynamic DNS > Dynamic DNS Clients" solution.
A DHCPv4 and DHCPv6 server can register the host name of a device that asked for a lease into a DNS server.
This already is/was possible with pfSense before, but then the host name is only known locally.
The DHCP ISC server (and kea also) can also use any other DNS server, so also my domain name server) to register the host name with the IP. That's not 'like' DDNS, it IS DDNS, and it also uses RFC2136 (which is a classic, very first DDNS method that existed out there).

As I'm using kea, and kea uses a separate process (program) for that, and pfSense has that program but isn't using it, I decide to use it.
Works great - an was pretty straight forward to implement.
And none of all this is a surprise as kea is written by the same guys who wrote "ISC DHCP", so they made it compatible.

Btw : not that I really need a LAN IPv6 (my NAS) so it can be accessed on a world Internet level, it just enables me to access my NAS over IPv4 or IPv6 anytime. It's more a "to be ready for the future" thing. And the future is here : 60+ % of all my pfSense LAN/WAN traffic is IPv6.

@CNLiberal I have never set up a DHCPv6-PD server, so I can't help with that.

@BigTulsa said in pfSense 2.7.2CE not working when trying to assign multiple interfaces:

I'm wondering if allowing the ia-na 0 is causing the problem here or if I should comment that out from the script. I will likely try it here shortly, but I wanted to jump in here to see if anyone has tried this?

Only one way to be sure :
packet capture the DHCPv6 traffic (dhcp6c and other) and see what 'you' send out and what your ISP box or DHCP4v6 send back as a result.

Be ware :of the reality : IPv4, after 5 decades or so, has reached the 'stable' situation and works pretty well.
IPv6 is another thing. There are the official IPv6 RFC's, and the joke of the century : every ISP interprets them 'differently'. So what works for me - doesn't work for you.
When dealing with IPv6, mention who is your ISP - what equipment you use on the other side of the pfSense WAN port.

Example, my ISP has a pretty good IPv6 support.
I get a IPv6 for my pfSense WAN, and a prefix for my LAN.
Here it comes : just one prefix, even if my pfSense wants more. So I can equip just one LAN with IPv6.
I use the pro version of the ISP Internet access of course. But my ISP (Orange, France) isn't aware of the fact that a company can use more the one LAN ..... (no joke 😕 )

My WAN DHCP6 settings :

1d91937c-1bd6-43fa-ba83-c658d10a97f2-image.png

If I change the /64 for 'something else' everything breaks.

edit : and my ISP box tells me :

f3a34e57-10b7-4aff-9d5e-0a0767aa7060-image.png

so it tells me that it has a /56 or 256 x /64 avaible ....

@BigTulsa said in pfSense 2.7.2CE not working when trying to assign multiple interfaces:

version of pfSense (2.7.2CE).

Hummm.
Your using bleeding edge technology = IPv6 prefixes for your pfSense LANs : what about using the bleeding edge solution : upgrade to 2.8.0 beta right away.
It works ...

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