@artafinde said in IPv6 connectivity NAT: DHCP6C logs A WAN interface, igb0, became active, so dhcp6c starts doing its work : The first part, where dhcp6c has process ID 867, goes well up until something/someone pulls the plug : dhcp6c[867]: transmit failed: Network is down So, djcp6c starts again : .... process ID is now 26116. It also ... vanishes. New process again : dhcp6c[26428]: transmit failed: Network is down but 26428 manages to get everything right : an IPv6, a prefix Reaching this phrase : got an expected reply, sleeping means all is well. I'm not saying that these multiple restarts with 7 second are not normal, maybe you can set up an initial "10 seconds or so" hold off, see the dhcp4 parameters ? (not sure if the dhcp6 process has the same process option, you'll need to see the man ?) I've this : [image: 1739862805019-0c2adff7-6ab2-4b7e-973d-ef6f810bdc03-image.png] = nothing checked as you can see and it works fine for me.

I'm using pfSense + 24.11 . The menu/settings structure is not exactly the same. I believe I found the equivalents, and tried to apply them. I just could not get IPv6 to work on my LAN. I even did a full factory reset of pfSense and started from scratch, following instructions in this thread. It's a no go. I'm using a Comcast XB8 in bridge mode, but don't think the modem makes any difference. IPv4 works great, including inbound for my Wireguard VPN.

working now New GUAs

https://redmine.pfsense.org/issues/15808 Should be in the next release 2.8/25.03 I think NAT64 might also come in that release. I'm hoping for custom dhcp options in KEA, but the old dhcp is a fallback. Then i need to wait for CLAT in Windows, which was talked about in a blog post last year, radio silence sinse then from MS

@Gertjan the alexas can dos my pihole all they want ;) that has zero to do with the cameras talking to the nvr, which is on an isolated network behind the nvr. And they could cut the power to the house as well. The nvr is on a ups and the cameras are poe - so while it won't last days should be able to get good 30 minutes or so of run time. Alexas in the landfill, what you have me do touch a light switch like a savage? ;)

@Bob-Dig That looks like it worked! Is there a limitation I should be aware of with how quickly those rules will update? I just don't want to leave an open hole in my firewall whenever my ISP drops the ball.

@Gertjan Oh - good observation - you know, my ISP had many issues recently, and my modem had to be restarted. Also, I added some new devices and reconfigured my DHCP server (new static mappings) several times recently. It seems like it might correspond to those events. Could it simply be a remnant of that? Since it hasn't happened in several days, might everything be OK? FYI: root 69058 0.0 0.1 13024 2796 - Ss 24Jan25 1:10.52 /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog Yes, just one instance, dating back.

@Gertjan OK, now I think I've hit a Heisenbug I noticed the rule specified the same port in the "From" and "To" port range, and the surrounding text said to leave the "To" port blank for a single port. I blanked out the "To" port and committed the change, and the ipv6 ssh forwarding started working. I made no other changes, and now the form fills in the "to" port with the same number, so it looks exactly like it did when it wasn't working. It appears the rule just needed to be updated, but I have no idea why since the update didn't actually change anything.

@JonathanLee said in Alias tables don't contain IPv6 addresses anymore: Is your zone transparent ? I had an issue with mine set to (type transparent) and it was causing issues Zone type is at default "transparent" not "type transparent".

@jhg Curious. I replaced the computer I originally ran pfSense on a few years ago. Other than changing the interface assignments, it just worked. I'm still using that new computer today. I'm on Rogers and they use a lot of the same hardware as Comcast. The first computer I ran pfSense on was a refurb HP compact computer and when it died I replaced it with the mini PC described in my sig.

Solved, and it's not pretty. A debug message pointed me to /var/db/dhcp6c_duid containing text. So I removed the file to give DHCP6 a chance to start fresh. Then I disabled and re-enabled the WAN interface, and now everything's working. When I look at that file now, it's binary, not text. Somehow, that file was preventing IPv6 connectivity. Now all I have to do is reboot a few LAN devices that are hanging on to their old delegated prefix :-)

@JKnott After coming back to this a few days later all the wifi clients are now getting ipv6. Must of been some sort of delay from when the ISP gives out the ip addresses.

@haunted If your prefix is consistent, you don't need DynDNS. I've had the same prefix for almost 6 years and just use a regular DNS server.

Issue still present exactly as described above. Confirmed via wireshark that pfsense will relay ULA requests from a GUA to active directory and AD will ignore it since no scope is establish for my GUA.

@JKnott I was younger than you when I got mine, but based upon your other historical background, I suspect that you're a few years older than me as well. Too bad we didn't know each other back then. I think we would have had a lot of fun. Thank you again for engaging with me in this discussion, and for keeping it civil. I've enjoyed the discussion, and look forward to communicating with you again.

@CatSpecial202 There's no such thing as broadcasts on IPv6. The closest to it is all nodes multicast, which is an ICMP6 message. FF00::/8 is multicast. Since IPv6 relies on multicasts for a lot, you want to be careful of what in that range you filter. For example I just saw a multicast to ff02::1, which is a router advertisement to all nodes. If you block that, you'll kill your network. FE80 the link local range and those shouldn't even be passing through pfSense. However, they are also critical to the operation of IPv6, so again be very careful of what you filter.

No, there isn't. miniupnpd itself doesn't support IPv6 ACLs. https://github.com/miniupnp/miniupnp/issues/694