@johnpoz said... I don't think so. Your interface should have a /64 on it... What you delegate would be under the delegation pool range. Your downstream device for example would grab an IP out of the /64 range, and then request a delegation for networks for it to use and hand out behind it.. Its wan would have an IP out of the /64, and it would get a say a /56 that it would use for delegation for stuff behind it. Meaning, what it delegates would not overlap with what it has itself... which is not allowed. Try it for yourself; I just did: Whatever the size you provide to the interface... Is the TOTAL range available to that interface, including all delegated ranges. If /64, then only /64 or smaller is available for any use under that interface. By using /56: I can set a /64 range for DHCPv6 of the interface AND I can allocate a lot of space for delegation (say, /60) In practical terms... if /48 is aaaa:bbbb:cccc:: and /56 for an interface is aaaa:bbbb:cccc:9900:: Then for that ifce DHCPv6, it has ...9900 through ...99ff available. So I can use ...9900 for my own /64 dhcp and ...9910-991f would be a nice /60 delegation etc. (BTW, I've learned to allocate from the left in a quad (abcd)... because :1: means :0001: not :1000: ... that took me a few moments to realize!)

@4920441-0 Does tcpdump show you anything? That's where I typically begin...

@derelict well said, and sums up my thoughts. Respective DUID state is nice, and it would be even nicer to track and adjust relatively on the pfSense side. Thanks for your time.

@netblues Quoting my self, recreated the bridge, enabled [image: 1647689757899-f2d80342-4a62-46ff-9e35-8e57d7b0eff7-image.png] in bridge advanced config and I know have a global ipv6 that works. I also checked it works on all bridged interfaces Will monitor this for stability

@jknott As suggested, I disabled DHCPv6 and switched SLAAC to "Unmanaged", and although the Android device picked up the correct IPv6 details (as it did before), it still was not able to ping the global IPv6 address of the pfSense interface for that VLAN, so the issue remained. At that point I decided to change the global IPv6 address of the pfSense interface for that VLAN (from ending ::1 to ending ::2) and I was able to successfully ping that address from the Android device. At that point the Android device was also able to successfully utilise the DNS server on that same address, so the Wi-Fi connection stayed up. Problem solved . I still don't know though why the Android devices on my network didn't like the ::1 address. As I said previously, no such problems with my Windows 10 and iOS devices. After that, rather than keeping the interface address ending ::2, I decided to follow the SLAAC approach and I updated the VLAN interface global IPv6 address to the combination of the network prefix (/64) with the EUI-64 interface identifier. All was still well after that; I could ping the address from my Android device and I could utilise the pfSense DNS Resolver. For the avoidance of doubt, all devices (Android, iOS and Windows 10) are now happy. DHCPv6 remains disabled and I'm only using SLAAC in "Unmanaged" mode. Only peculiarity to note is that as long as DHCPv4 is active on the same VLAN, Windows 10 does not pick up the IPv6 DNS servers, it uses the IPv4 DNS servers instead. As soon as I disable DHCPv4 though, Windows 10 picks up the IPv6 DNS servers (via SLAAC). From what I've read, this seems to be a Windows 'feature' .

@flo-0 You could get a /48 and it will be be static. I'm using two of them, and they are fine for years now. But there is probably a trade of : speed. See https://www.tunnelbroker.net/ and Configuring IPv6 Through A Tunnel Broker Service. I'm using a existing domain name on my LAN's and the hots names with IPv6 are written into the DNS server and thus are known globally. Some RFC 2136 scheme is used for this.

@ahsunh Setting up DHCPv6 on a VLAN is exactly the same as on the LAN. Just make sure you use a different IPv6 Prefix ID for each interface. However, why are you using DHCPv6? It won't work with Android devices.

@dwighthenry I have not set up a DHCPv6 server, as I use SLAAC. However, ULA addresses start with fc or fd. There was a distintion between the two in that the fc block was supposed to use some server to co-ordinate assignments, though I don't believe that went anywhere. I don't know what could cause that error. What protection are you referring to? Given that ULA addresses are not to be passed over the Internet, there's not much to attack you.

OK, I think I figured it out looking at the tunnel interface MTU on the firewall. BY DEFAULT it sets to 1280 unless you set it to match the MTU on the other end of the tunnel - 1480 per HE. When I set to 1480, it no longer sent PMTU for 1280, but for 1480 like it's supposed to. Not at all intuitive... tracepath google.com 1?: [LOCALHOST] 0.029ms pmtu 1500 1: 2001:470:e073:101::2 0.392ms 1: 2001:470:e073:101::2 0.407ms 2: 2001:470:e073:101::2 0.425ms pmtu 1480 2: tunnel202636.tunnel.tserv13.ash1.ipv6.he.net 29.177ms 3: 10ge2-2.core1.ash1.he.net 13.809ms 4: pr61.iad07.net.google.com 12.468ms tracepath google.com 1?: [LOCALHOST] 0.033ms pmtu 1400 1: 2001:470:e5bf:1001:cafe:dead:beef:1 8.834ms 1: 2001:470:e5bf:1001:cafe:dead:beef:1 0.516ms 2: 2001:470:e5bf:3000::2 1.576ms 3: tunnel161881.tunnel.tserv13.ash1.ipv6.he.net 7.791ms 4: 10ge2-2.core1.ash1.he.net 7.385ms 5: pr61.iad07.net.google.com 7.862ms

@jknott I went back and looked things over for a couple of day. Looking at Wireshark, I wasn't seeing any ICMPv6 traffic at all coming over to the wired side of my network from the wireless side. So, I assumed it was something wrong with bridge mode on that Amplifi HD wireless router. I ordered a small netgear wireless access point to replace it with. But, today, as I was preparing for that WAP, I noted my prefix in the WAN interface wasn't what I thought it was. I used to have it set up for a /56. But, it was set for /64 and wasn't even set to send a hint. I changed that and now have IPv6 addresses on the phones. I made no other changes. Oh, well. Sorry for the trouble. Thanks for the help.

@kimble said in IPv6 Gateway monitoring broken in 2.6.0?: Maybe it's clever enough to bind to a LAN address in that instance? I've no idea. You have to specify a source address by using the -S option in ping. I just did it, using my LAN global address.

@jkmuk Do a packet capture on DHCPv6. To do this, shut down pfsense and disconnect the WAN cable. Reboot and start Packet Capture Plug in the WAN cable. After a couple of minutes, download the capture file and post it here.

This issue is reproduced by Netgate support and tracked as https://redmine.pfsense.org/issues/12790

@jknott as I said this setting work for me perfectly.

@gertjan I applied it to all interfaces in a floating rule. Why Not right? Yeah. Its an alias. Netflix was sort of sneaky by not blocking everything. Had me fooled for a minute there. I also handed out static IPV6 addresses to everything connected to the pfsense including my XMPP chat server and phone server. Interestingly, that totally fixed NAT issues like broken video and broken voice even when only one side of the conversation was on IPV6 and the other side was on IPV4. Thats the main reason I want everyone to transition to IPV6. No more NAT. No more buying a public IP for every server. No more need for STUN, ICE, Jingle, WebRTC, TURN servers or crap like that.

@wbond Ok, great. The dull thing about "ISP router in in router mode" is : it should work, as my he IPv6 tunnels are all up right now @work and also the one @home. I'm using the he.net POP in Paris. Note : he.net is supplying me with IPv6, as my ISP doesn't know what that is (@work) - or, @home, they just supply on /64. so none are available for the LAN's. Btw : always check the tunnel status. And if doubt, the forum on he.net.