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

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