@Gertjan Yes I'm running in debug mode Jul 11 16:29:49 dhcp6c 82560 extracted an existing DUID from /var/db/dhcp6c_duid: 00:01:00:01:2b:8f:81:6a:20:7c:14:a1:bf:06 Jul 11 16:29:49 dhcp6c 82560 failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory Jul 11 16:29:49 dhcp6c 82560 failed initialize control message authentication Jul 11 16:29:49 dhcp6c 82560 skip opening control port Jul 11 16:29:49 dhcp6c 82560 <3>[interface] (9) Jul 11 16:29:49 dhcp6c 82560 <5>[igb0] (4) Jul 11 16:29:49 dhcp6c 82560 <3>begin of closure [{] (1) Jul 11 16:29:49 dhcp6c 82560 <3>[script] (6) Jul 11 16:29:49 dhcp6c 82560 <3>["/var/etc/dhcp6c_wan_dhcp6withoutra_script.sh"] (46) Jul 11 16:29:49 dhcp6c 82560 <3>end of sentence [;] (1) Jul 11 16:29:49 dhcp6c 82560 <3>end of closure [}] (1) Jul 11 16:29:49 dhcp6c 82560 <3>end of sentence [;] (1) Jul 11 16:29:49 dhcp6c 82560 <3>[id-assoc] (8) Jul 11 16:29:49 dhcp6c 82560 <13>[na] (2) Jul 11 16:29:49 dhcp6c 82560 <13>[1] (1) Jul 11 16:29:49 dhcp6c 82560 <13>begin of closure [{] (1) Jul 11 16:29:49 dhcp6c 82560 <3>end of closure [}] (1) Jul 11 16:29:49 dhcp6c 82560 <3>end of sentence [;] (1) Jul 11 16:29:49 dhcp6c 82560 called Jul 11 16:29:49 dhcp6c 82560 some IA configuration defined but not used Jul 11 16:29:49 dhcp6c 82560 called Jul 11 16:29:49 dhcp6c 82642 reset a timer on igb0, state=INIT, timeo=0, retrans=891 Jul 11 16:29:49 dhcp6c 82642 Sending Solicit Jul 11 16:29:49 dhcp6c 82642 a new XID (93ca57) is generated Jul 11 16:29:49 dhcp6c 82642 set client ID (len 14) Jul 11 16:29:49 dhcp6c 82642 set elapsed time (len 2) Jul 11 16:29:49 dhcp6c 82642 send solicit to ff02::1:2%igb0 Jul 11 16:29:49 dhcp6c 82642 reset a timer on igb0, state=SOLICIT, timeo=0, retrans=1091 Jul 11 16:29:49 dhcp6c 82642 receive advertise from fe80::88ce:87ff:fec6:156a%igb0 on igb0 Jul 11 16:29:49 dhcp6c 82642 get DHCP option client ID, len 14 Jul 11 16:29:49 dhcp6c 82642 DUID: 00:01:00:01:2b:8f:81:6a:20:7c:14:a1:bf:06 Jul 11 16:29:49 dhcp6c 82642 get DHCP option server ID, len 14 Jul 11 16:29:49 dhcp6c 82642 DUID: 00:01:00:01:21:56:39:cc:fa:32:37:34:e3:9f Jul 11 16:29:49 dhcp6c 82642 get DHCP option identity association, len 40 Jul 11 16:29:49 dhcp6c 82642 IA_NA: ID=1, T1=1000, T2=2000 Jul 11 16:29:49 dhcp6c 82642 get DHCP option IA address, len 24 Jul 11 16:29:49 dhcp6c 82642 IA_NA address: 2a06:4000:8888:ffff::2 pltime=3000 vltime=4000 Jul 11 16:29:49 dhcp6c 82642 get DHCP option DNS, len 32 Jul 11 16:29:49 dhcp6c 82642 get DHCP option IA_PD, len 41 Jul 11 16:29:49 dhcp6c 82642 IA_PD: ID=1, T1=1000, T2=2000 Jul 11 16:29:49 dhcp6c 82642 get DHCP option IA_PD prefix, len 25 Jul 11 16:29:49 dhcp6c 82642 IA_PD prefix: 2a06:4000:8888::/48 pltime=3000 vltime=1546855634413031328 Jul 11 16:29:49 dhcp6c 82642 server ID: 00:01:00:01:21:56:39:cc:fa:32:37:34:e3:9f, pref=-1 Jul 11 16:29:49 dhcp6c 82642 reset timer for igb0 to 0.958394 Jul 11 16:29:49 dhcp6c 82642 receive advertise from fe80::88ce:87ff:fec6:156a%igb0 on igb0 Jul 11 16:29:49 dhcp6c 82642 get DHCP option client ID, len 14 Jul 11 16:29:49 dhcp6c 82642 DUID: 00:01:00:01:2b:8f:81:6a:20:7c:14:a1:bf:06 Jul 11 16:29:49 dhcp6c 82642 get DHCP option server ID, len 14 Jul 11 16:29:49 dhcp6c 82642 DUID: 00:01:00:01:21:5a:37:e1:96:96:78:4c:ae:6d Jul 11 16:29:49 dhcp6c 82642 get DHCP option identity association, len 40 Jul 11 16:29:49 dhcp6c 82642 IA_NA: ID=1, T1=1000, T2=2000 Jul 11 16:29:49 dhcp6c 82642 get DHCP option IA address, len 24 Jul 11 16:29:49 dhcp6c 82642 IA_NA address: 2a06:4000:8888:ffff::2 pltime=3000 vltime=4000 Jul 11 16:29:49 dhcp6c 82642 get DHCP option DNS, len 32 Jul 11 16:29:49 dhcp6c 82642 get DHCP option IA_PD, len 41 Jul 11 16:29:49 dhcp6c 82642 IA_PD: ID=1, T1=1000, T2=2000 Jul 11 16:29:49 dhcp6c 82642 get DHCP option IA_PD prefix, len 25 Jul 11 16:29:49 dhcp6c 82642 IA_PD prefix: 2a06:4000:8888::/48 pltime=3000 vltime=1546855634413031328 Jul 11 16:29:49 dhcp6c 82642 server ID: 00:01:00:01:21:5a:37:e1:96:96:78:4c:ae:6d, pref=-1 Jul 11 16:29:50 dhcp6c 82642 picked a server (ID: 00:01:00:01:21:56:39:cc:fa:32:37:34:e3:9f) Jul 11 16:29:50 dhcp6c 82642 Sending Request Jul 11 16:29:50 dhcp6c 82642 a new XID (61396e) is generated Jul 11 16:29:50 dhcp6c 82642 set client ID (len 14) Jul 11 16:29:50 dhcp6c 82642 set server ID (len 14) Jul 11 16:29:50 dhcp6c 82642 set elapsed time (len 2) Jul 11 16:29:50 dhcp6c 82642 send request to ff02::1:2%igb0 Jul 11 16:29:50 dhcp6c 82642 reset a timer on igb0, state=REQUEST, timeo=0, retrans=909 Jul 11 16:29:50 dhcp6c 82642 receive reply from fe80::88ce:87ff:fec6:156a%igb0 on igb0 Jul 11 16:29:50 dhcp6c 82642 get DHCP option client ID, len 14 Jul 11 16:29:50 dhcp6c 82642 DUID: 00:01:00:01:2b:8f:81:6a:20:7c:14:a1:bf:06 Jul 11 16:29:50 dhcp6c 82642 get DHCP option server ID, len 14 Jul 11 16:29:50 dhcp6c 82642 DUID: 00:01:00:01:21:56:39:cc:fa:32:37:34:e3:9f Jul 11 16:29:50 dhcp6c 82642 get DHCP option identity association, len 40 Jul 11 16:29:50 dhcp6c 82642 IA_NA: ID=1, T1=1000, T2=2000 Jul 11 16:29:50 dhcp6c 82642 get DHCP option IA address, len 24 Jul 11 16:29:50 dhcp6c 82642 IA_NA address: 2a06:4000:8888:ffff::2 pltime=3000 vltime=4000 Jul 11 16:29:50 dhcp6c 82642 get DHCP option DNS, len 32 Jul 11 16:29:50 dhcp6c 82642 get DHCP option IA_PD, len 41 Jul 11 16:29:50 dhcp6c 82642 IA_PD: ID=1, T1=1000, T2=2000 Jul 11 16:29:50 dhcp6c 82642 get DHCP option IA_PD prefix, len 25 Jul 11 16:29:50 dhcp6c 82642 IA_PD prefix: 2a06:4000:8888::/48 pltime=3000 vltime=1546855634413031328 Jul 11 16:29:50 dhcp6c 82642 dhcp6c Received REQUEST Jul 11 16:29:50 dhcp6c 82642 nameserver[0] 2a06:4000:0:6::6 Jul 11 16:29:50 dhcp6c 82642 nameserver[1] 2a06:4000:0:6::5 Jul 11 16:29:50 dhcp6c 82642 executes /var/etc/dhcp6c_wan_dhcp6withoutra_script.sh Jul 11 16:29:50 dhcp6c 36281 dhcp6c REQUEST on igb0 - running rtsold Jul 11 16:29:50 dhcp6c 82642 script "/var/etc/dhcp6c_wan_dhcp6withoutra_script.sh" terminated Jul 11 16:29:50 dhcp6c 82642 removing an event on igb0, state=REQUEST Jul 11 16:29:50 dhcp6c 82642 removing server (ID: 00:01:00:01:21:56:39:cc:fa:32:37:34:e3:9f) Jul 11 16:29:50 dhcp6c 82642 removing server (ID: 00:01:00:01:21:5a:37:e1:96:96:78:4c:ae:6d) Jul 11 16:29:50 dhcp6c 82642 got an expected reply, sleeping.

@Gertjan plus I have that authenticated ntp patch on that file also

@Gertjan Fixed it. I had on the interface address both an IPv6 address and an "IPv4 address embedded in the IPv6 address (this is known as IPv6-mapped IPv4 addresses or IPv6 embedded IPv4 addresses)" before that is normally not for interfaces only the static device assignments so that is corrected my Pv6-mapped IPv4 addresses or IPv6 embedded IPv4 addresses are now only on the Lan devices and not on the firewall interfaces. [image: 1752100262620-screenshot-2025-07-09-at-15.29.37-resized.png]

I ran this command after upgrading from 2.7.2 to 2.8.0, as I started experiencing significant issues with my work VPN connection behind the firewall. Upon checking the connection properties, I noticed that the VPN was attempting to connect through an IPv6 gateway. What’s particularly strange is that while the VPN would eventually connect, it often required multiple connection attempts before any traffic would actually pass through. I’m hoping this fix resolves the issue moving forward—fingers crossed for the next time I need to connect.

@koyaan134 And just to be clear - as soon as I take a look at it again, it's back up.

@crazypotato142 said in [solved] WAN gets IPv6 but LAN can't: Wouldn't that mean it has the connectivity and with a prefix translation I could use IPv6? Like Teredo or HE. Imho : don't invest any time in using Toredo. That's a dying concept. HE (tunnel broker) is something else. I've been using it for years, as they implement a clean and close to perfect, one of the best IPv6 implementations. Their services are not free ! That is, it won't cost you any money, and they even send you a free (yes) T-Shirt when you finish their IPv6 certification process. It's back to school-time-again, and do their multiple choice exam. They offer a /64 to start with, but don't bother, go for the whopping /48 right way 65535 prefixes. Your WAN will have a IPv6 GUA. Downsides : The POP needs to be close to you. The connection can be interpreted by the site you visit as some sort of VPN connection (there is a work around available if you use pfBlockerng). The POPs can be crowed, so the speed won't be stellar.

@johnpoz Dear John As I suspected, the error was with the provider, after my request they solved the IPv6 problem. I am very grateful to you for your support.

@GeorgePatches See the images below, maybe this can help. You could give it a try. [image: 1749066970847-2fb49e34-f096-4f24-af9e-6ac1e6487cf5-image.png] [image: 1749067000391-2fe0db2f-1676-45bf-8182-717173a8742c-image.png] Thanks! Raj

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

@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 : [image: 1746690385172-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 : [image: 1746092824335-1d91937c-1bd6-43fa-ba83-c658d10a97f2-image.png] If I change the /64 for 'something else' everything breaks. edit : and my ISP box tells me : [image: 1746093034898-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.

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!