That was exactly what I needed. Thank you so much!

I have been working on a similar setup. Dual WAN IPv4+IPv6. I get native IPv4 from my ISP. For IPv6 I have been using Hurricane Electric for at least a decade. Recently, I stumbled upon a tunnel service that does both IPv4 and IPv6. This makes it possible to rather easily move services, yet keeping IPs the same, both IPv4 and IPv6. But that's more of a backstory. I have been researching quite the same problem you describe. Packets that are generated on the router (e.g. ICMP TTL Exceeded when doing a traceroute) should be sent back through the same interface they entered, but for IPv6, this doesn't work. It seems that in FreeBSD, the backing operating system for pfSense, this is simply not implemented for IPv6. There is code in review for this, but it may take some more time before that reaches FreeBSD itself, and consequently pfSense. Hope this helps.

With thanks to Netgate tech support, the solution was to turn off my interface's Block private networks and loopback addresses. Upon reflection, this does make sense and with it disabled, my DHCPv6 server with RA set to either managed or assisted is now responding to DHCPv6 client requests and issuing assignments. And yet, I will submit a feature request such that when the DHCPv6 Server is enabled, an alert should be posted saying "but you need to disable Block private networks and loopback addresses on the interface, otherwise the DHCPv6 server will never receive the incoming IPv6 client's request for a local RA server..."

@rajeshh That's called "dual stack" and will be needed for a while yet. If the games support IPv6, then it will work that way for you. The operating systems prefer IPv6, but will use IPv4 when necessary.

Of course as soon as I post this I redid it with a new vhid and a FULLY expanded ipv6 address. No :: no :0: and no :3: was done, that fixed it and my routes came up with the upstream router. I still would like to find that redmine issue so I can track the fix. If anyone knows the # I would appreciate it. Thanks

me too, what this is? Aug 24 05:38:00 kernel sa6_recoverscope: embedded scope mismatch: fe80:c::f298:38ff:fe93:d380%13. sin6_scope_id was overridden

@HG You also have to look at how often DHCPv6-PD executes and whether it does after PPPoE comes up. I have a capture of DHCPv6 at boot up and the first renewal and it's over 22 hours between them.

Hey, I'm not sure if this is still relevant but restarting the service at status>gateways fixed it for me. However, I was already able to ping my IPv6 gateway from the diagnostics>ping tool. [image: 1597238590711-untitled-2.png]

@johnpoz Config is done and working as expected. Got a /48 from HE and /50 subnets to LAN. [image: 1597076892547-9fc6b336-5d05-4538-b512-87464720b176-image.png] DHCPv6 Server & RA (/56 to downstream CPEs) [image: 1597077968310-8466e9df-c67d-489c-a7cf-09743b7f7b14-image.png] RA [image: 1597078154820-3bffbe77-935e-49ce-b134-6c532079aa6b-image.png] Tested with Android 8/9, Android TV 7.1.2, iOS 9.3.6, Windows 10, Arch Linux, OpenWRT, and some others Home Gateways.

@qsystems If you are using Unifi APs (Multicast Enhancement, rings bell for those) make sure you have the latest firmware loaded, they have had some issues with multicast recently and supposedly corrected with newer firmware.

@kesawi said in Planning for IPv6 /48 allocation: My question for anyone who may know, is it possible to have two separate concurrent DHCPv6 scopes with pfSense and Windows? If so what do I need to do to get it to work? I doubt it, as there would be no way to determine which DHCPv6 server was desired. I assume if I give up on DHCPv6 and just go to SLAAC for both then ULA and GUA will still co exist? That's what I have. Also, if you have Android devices, you don't want to use DHCPv6. For some idiotic reason, Android doesn't support it. I have two internal DNS severs. Do I need to specify both their respective ULA and GUA addresses in the RA settings, or can I just specify the ULA addresses? You can use either GUA or ULA address. However, you don't have to specify an address as pfSense does that by default. It uses it's own address, unless you specify otherwise.

@johnpoz Got it, thanks! Somehow totally missed that page. One DHCP lease renew later and everything seems to be working good now.

@viktor_g Thanks so much for your help. After applying the second patch things are working as expected. Thanks again.

Hmm, maybe adding a static route would solve this? If you go to System, Routes and Static routes.

It seems that I have found the issue... By analyzing the tcpdump, I have noticed that there was another ip that was answering to the request of the dhcp. The problem is that I didn't know what it was. It was in the ndp table of my computer, it was in the neighbour list of the switch. At the end it was a stupid raspberry that was advertising itself as router. Disconnected, everything works like a charm. Thanks for the help anyway. Case closed!

@JKnott said in LAN unable to talk over WAN IPv6 after reboot or reinstall of Suricata: @OffstageRoller said in LAN unable to talk over WAN IPv6 after reboot or reinstall of Suricata: I mentioned in my OP that when this happens, I can both ping and ping6 from the pfSense box itself. It's only my local network that can't talk over IPv6 to the public internet. You have to test various things to isolate the problem. You were able to ping from pfSense, so that shows the WAN connection works. When you try from the LAN and watch the WAN, you can determine if the problem is with pfSense or elsewhere. This sort of thing is just basic troubleshooting. You try to isolate where the problem is coming from. That was something RMO asked initially, and yes, my default deny IPv6 rule is blocking my LAN from reaching the internet over IPv6. Almost all of my rules have the source (LAN net) that matches the interface where the rule exists. And it appears that after a reboot, the devices that have DHCP6 addresses are not considered part of that LAN net source, and therefor they get caught by the default deny rule. Interestingly enough, I did what you suggested in RMO's thread and enabled Do not allow PD/Address release and that appears to have fixed my issue. Should it have though? I would expect that might be the case if you had addresses hard coded somewhere and the prefix changed. But they're not hard coded, and my IPv6 prefix does not change :). However, after a reboot, pfSense does not appear to be storing the IPv6 prefix in my "net" source rules I mentioned above. And it's only after I renew my DHCP lease (which doesn't change the lease), that that my pass rules start allowing IPv6 through, that something gets updated within pfSense and my prefixes for each /64 LAN are now stored in the "LAN net" rule. Hopefully that makes sense? I'm happy to test other scenarios to help narrow things down further.

@daygle said in IPv6 DHCPv6 Leases Not Being Assigned on pfSense LAN Network: No matter what I change I just cannot seem to see any leases in the 'DHCPv6 Leases' section. Am I missing something? Hoping someone is able to point me in the right direction to enable IPv6 on my LAN. Is your modem in bridge or gateway mode? It has to be in bridge mode. If in gateway, only devices directly connected to it will get IPv6 addresses. For example, I get a /56 prefix from my ISP, with the modem in bridge mode, which pfSense can then split into 256 /64s. In gateway mode, I only get as single /64, which cannot be passed through pfSense.

@cmcqueen I'm in Canada, so it's not an Aussie thing. As for why it's there, previously it wasn't and the prefix would frequently change. I suppose there is a reason why someone would want to always release the prefix, but I don't know what that is, other than perhaps changing ISP or something.