@jimp Ok, agree to the technical details. I wanted to give a hint for how to solve OT's need for automatic registering. I checked again how it works. The information comes definitive via DNS-KEY from the pfsense gateway IP. I see no need to store the name in dhcp too when the passtrough to BIND works this way. Obfuscated output from BIND-log: 28-Sep-2018 21:03:12.656 update: client @0x8087fec00 172.31.18.1#22770/key ddns-key: view internal: updating zone 'int.somedomain.org/IN': update unsuccessful: some-host.int.somedomain.org: 'name not in use' prerequisite not satisfied (YXDOMAIN) 28-Sep-2018 21:03:12.658 update: client @0x8087fec00 172.31.18.1#22770/key ddns-key: view internal: updating zone 'int.somedomain.org/IN': deleting rrset at 'some-host.int.somedomain.org' TXT 28-Sep-2018 21:03:12.658 update: client @0x8087fec00 172.31.18.1#22770/key ddns-key: view internal: updating zone 'int.somedomain.org/IN': adding an RR at 'some-host.int.somedomain.org' TXT "024fba2obfuscatednumb2a25secret75b" 28-Sep-2018 21:03:12.658 update: client @0x8087fec00 172.31.18.1#22770/key ddns-key: view internal: updating zone 'int.somedomain.org/IN': deleting rrset at 'some-host.int.somedomain.org' AAAA 28-Sep-2018 21:03:12.658 update: client @0x8087fec00 172.31.18.1#22770/key ddns-key: view internal: updating zone 'int.somedomain.org/IN': adding an RR at 'some-host.int.somedomain.org' AAAA 2a0x:xxxx:xxxx:5af1:xxxx:xxxx:ef8f:xxxx 28-Sep-2018 21:03:12.661 update: client @0x8087fec00 172.31.18.1#22770/key ddns-key: view internal: updating zone '1.f.a.x.x.x.x.x.x.x.x.x.x.x.a.2.ip6.arpa/IN': adding an RR at 'x.5.7.x.x.8.f.e.x.x.2.a.x.d.4.2.1.x.a.5.1.x.x.x.x.x.x.x.x.0.a.2.ip6.arpa' PTR some-host.int.somedomain.org.

I can confirm, that restoring DUID helped to change to former subnet. And now there is a entry stored in 2.4.4 config. <global-v6duid>00:01:00:01:22:56:08:42:00:0a:9b:a2:91:a3</global-v6duid>

@jimp This seems to have fixed my Android device as well. Before upgrade to 2.4.4, I was unable to have v6 running on my network because it would cause my cellphone to constantly drop it's WiFi connection because it though that it didn't have an Internet connection. After the upgrade, it works perfectly.

That would be a dream! For now I wouldn't hold my breath. FIOS doesn't even support IPv6 and as far as I know since they've been selling off the business to Frontier I doubt there are even any plans to. Shame.

No. The point was that rule does nothing. It should be deleted. I still maintain your issue is on the client. I suppose it could possibly be a setting in the DHCPv6 server or something but I can't imagine what that would be. Maybe something else on that VLAN issuing router advertisements? Just guessing.

@derelict said in IPv6 with track interface on LAN stopped working: The DUID should be saved in the config anyway. I use DUID-LLT. You can manually get a new time in seconds with date "+%s" If you want the DUID-LLT to more closely resemble the one pfSense generates, use this, since they actually calculate from 1/1/2000 instead of 1/1/1970... expr $(date +%s) - 946684800

@mc-address said in Change NPT settings via command line?: Unfortunately i don't get a static prefix from my ISP and so the prefix changes everytime the connection is renewed. On the WAN Interface page, ensure "Do not allow PD/Address release" is selected.

@nogbadthebad said in N00B Question: How do I add IPv6 link-local address manually?: Does your VM software support IPv6 ? Yes and it's Hyper-V. IPv6 is enabled. LAN-interface has a IPv6 link-local address.

@heper said in Hetzner & pfSense: try to get the /56 anyways ... sometimes isp's say they only supply the /64 but in reality they'll route /56 prefix for each customer if you setup the dhcp-client to get a /56, it might just work or get another isp or spend the €50 I won't get any IPv6 prefix from DHCPv6 as it's static only configuration, so your idea does not apply. EDIT: They are routing my prefix though a link local address which my WAN interface is lacking. :(

Since no one is answering, I did a little research. This appears to be a valid DHCP server/relay solicitation. It doesn't go anywhere because there's no DHCP server/relay on the subnet, because in turn the subnet has been delegated to us from the ISP. radvd is running but we're using stateless autoconfiguration to allocate addresses. Should I be running a DHCPv6 relay in this situation? Or is stateless autoconfiguration enough? It seems to be working fine at the moment.

@bimmerdriver said in Survey of ISP support for Dual-Stack IPv4/IPv6 Networking: They do not support IA_NA or IA_NT. So you meant to say IA_NA or IA_NA? Not really sure what you meant. IA_NA or IA_TA?

Just to let anyone with the same problem know, for a few days now, the problem suddenly occured again. 2a01:111:f307:1790::f001:7a5 and 2a01:111:f335:1792::f001:7a5 exist and both have an AAAA record but they seem to not react on IPv6 connections. I have 3 machines here which are not updating for a few days now except I disable IPv6 for a second, so that they can reach the update server by IPv4. I'm now trying suggested solutions above. Kind of a weird issue. Edit: Rejecting IPv6 packets to sls.update.microsoft.com servers seems to be a workaround.

Spoke too soon... It worked for a bit then stopped after I rebooted pfsense.

The ISP is Spectrum/TimeWarner. I'll call them tomorrow, but you don't get to talk to engineers, just call center people. Most of them can't even spell IPv6, much less tell you anything about it. Another odd thing, I rebooted pfSense and then checked the DHCP logs to see if I could confirm the /56 that was being handed out. I didn't see anything in the log at all for dhcp6 (yes, there was stuff in there before...) : # clog /var/log/dhcpd.log | grep dhcp6 # <------ ¯\_(ツ)_/¯ radvdump shows that the /64s being offered there have valid lifetimes of infinity : prefix 2604:2000:ffc0:4::/64 { AdvValidLifetime infinity; # (0xffffffff) AdvPreferredLifetime infinity; # (0xffffffff) AdvOnLink on; AdvAutonomous off; AdvRouterAddr off; }; # End of prefix definition So maybe pfSense is caching this and just re-using it without triggering dhcp6c at all? I know it's not in config.xml so maybe on the filesystem somewhere? I have to look at the code to see if this is what's actually happening. I'll try to do some more packet captures as well.

@gertjan said in IPv6 Network details from ISP: Ah, yeah ! Can we have FTP back ?? Please ? ^^ How about VoIP or some games, where you need to use an STUN server to tell the devices what the real world address is for something hidden behind NAT. There's also IPSec authentication headers, which are broken by NAT. What if you want to run two servers, running the same protocal, behind NAT? Then you need to do remap some port numbers.

Ok so I rebooted after installing pfblockerng and now I can’t get my ipv6 address back again ‍️

@msf2000 : for what it's worth : my settings and yours (see your image) are the same. I have an only-win7 network (9 PC's) and a 2008R2 : never had anything to do so IPv6 work on LAN. for all my PC's and devices IPv6 DHCP settings : [image: 1536123333376-f68b6cd7-82ff-4587-b6d9-172b032f36b4-image-resized.png] Btw : For most devices I set DHCPv6 Static Mappings : [image: 1536123668651-6c7021f1-317d-45da-b193-1ec739d55342-image-resized.png] Btw : Using Win7 for a company. I ruled out Windows 8.x for a company, and, my opinion, Windows 10 isn't still ready yet, I guess I'll be using it in a year or so ... A "route print" on a Win7 PC : C:\Users\Réception-Gauche>route print =========================================================================== Liste d'Interfaces 10...b8 ac 6f 47 2c 77 ......Broadcom NetLink (TM) Gigabit Ethernet 1...........................Software Loopback Interface 1 =========================================================================== IPv4 Table de routage =========================================================================== Itinéraires actifs : Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique 0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.6 200 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306 192.168.1.0 255.255.255.0 On-link 192.168.1.6 356 192.168.1.6 255.255.255.255 On-link 192.168.1.6 356 192.168.1.255 255.255.255.255 On-link 192.168.1.6 356 224.0.0.0 240.0.0.0 On-link 127.0.0.1 306 224.0.0.0 240.0.0.0 On-link 192.168.1.6 356 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306 255.255.255.255 255.255.255.255 On-link 192.168.1.6 356 =========================================================================== Itinéraires persistants : Aucun IPv6 Table de routage =========================================================================== Itinéraires actifs : If Metric Network Destination Gateway 10 266 ::/0 fe80::212:3fff:feb3:5875 1 306 ::1/128 On-link 10 18 2001:470:1f13:5c0::/64 On-link 10 266 2001:470:1f13:5c0:2::c6/128 On-link 10 266 fe80::/64 On-link 10 266 fe80::75cd:7073:d0a4:bc7c/128 On-link 1 306 ff00::/8 On-link 10 266 ff00::/8 On-link =========================================================================== Itinéraires persistants : Aucun C:\Users\Réception-Gauche>

@isaacfl said in Cannot route IPv6 - Frustrated: LOCAL_SUBNETS_v6 HILARIOUS! That was is! The rule change fixed it. I used LAN NET because it was set up that way for the IPv4 rule. Thanks for walking through this mess with me. I Learned a lot.

@johnpoz The maximum working MSS is 1440 in my LAN interface setup in pfSense. 1280 also works. (the tracepath result gave me the same result as for you) As I said, I used 1220 because I found that post https://forum.netgate.com/topic/73573/massive-http-ipv6-connectivity-issues/8 where the solution was to set the MSS to 1220. I’m setting IPv6 in my « home » LAN, to learn more about IPv6 but also to have a fully functional IPv6 connection. I hope that’s the only problem I’ll find about my IPv6 setup. Again, thanks for all the resource you shared.