@bimmerdriver said in ICMPv6 not working ipv6-test.com: In the case of Telus, the unique part consists of 24 alphanumeric characters using 0...9 and a...z. On Rogers, the IPv4 host name is based on the cable modem MAC address and WAN MAC and ends with .cpe.net.cable.rogers.com On IPv6, it's based on the cable modem MAC and the LAN MAC and ends with .cpe.net6.cable.rogers.com. I have absolutely no idea why the LAN MAC is used.

@wre136 I bet on https://redmine.pfsense.org/issues/8934 have own DNS on FreeBSD and get many problems with IPv6 DNS and Fragments. Disabling scrubbing helps. But then IPv4 DNS has same problems :-( Oct 9 17:25:41 host1 kernel: ipfw: 65300 Deny TCP [2001:500:e::1] [2axx:xxxx:xxxx:xxxx::53] in via bge0 (frag 1217fb81:188@9856) Oct 9 17:25:57 host1 kernel: ipfw: 65300 Deny TCP [2001:500:f::1] [2axx:xxxx:xxxx:xxxx::53] in via bge0 (frag 4d6091d8:188@9856) Oct 9 17:26:45 host1 kernel: ipfw: 65300 Deny TCP [2001:500:e::1] [2axx:xxxx:xxxx:xxxx::53] in via bge0 (frag 350be3db:188@9856) Oct 9 17:31:29 host1 kernel: ipfw: 65300 Deny UDP [2001:500:40::1] [2axx:xxxx:xxxx:xxxx::53] in via bge0 (frag b576286c:361@9856) Oct 9 17:51:24 host1 kernel: ipfw: 65300 Deny UDP [2001:470:1a::1] [2axx:xxxx:xxxx:xxxx::53] in via bge0 (frag 8533c2a5:642@9856) Oct 9 17:51:26 host1 kernel: ipfw: 65300 Deny UDP [2001:5a0:10::1] [2axx:xxxx:xxxx:xxxx::53] in via bge0 (frag e06893c2:650@9856) Oct 9 17:53:07 host1 kernel: ipfw: 65300 Deny UDP [2001:67c:18c4:2000::11:53] [2axx:xxxx:xxxx:xxxx::53] in via bge0 (frag 55df3089:362@9856) Oct 9 18:11:05 host1 kernel: ipfw: 65300 Deny UDP [2001:500:48::1] [2axx:xxxx:xxxx:xxxx::53] in via bge0 (frag 8424932b:361@9856) Oct 9 18:11:25 host1 kernel: ipfw: 65300 Deny UDP [2001:500:b::1] [2axx:xxxx:xxxx:xxxx::53] in via bge0 (frag 9da68734:361@9856) Oct 9 18:14:41 host1 kernel: ipfw: 65300 Deny UDP [2001:500:c::1] [2axx:xxxx:xxxx:xxxx::53] in via bge0 (frag 69a41126:361@9856) Oct 9 18:18:05 host1 kernel: ipfw: 65300 Deny UDP [2001:500:40::1] [2axx:xxxx:xxxx:xxxx::53] in via bge0 (frag a639e4fd:361@9856)

I have a similar situation here, running 2.4.4 on bare metal and my firewall log is giving me this: Oct 8 17:29:27 fw2-hvk filterlog: 145,,,11000,ixl0.504,match,block,in,6,0x00,0x0f7c6,1,UDP,17,114,fe80::16cc:20ff:fe94:3f97,ff02::1:2,546,547,114 2.4.4-RELEASE (amd64) built on Thu Sep 20 09:03:12 EDT 2018 FreeBSD 11.2-RELEASE-p3 I'm running CARP while this machine is master. I deactivated all rules that have IPv6 in it for that given interface. Requests still being blocked. I deactivated Block Bogon for that interface. Problem persists. I have no floating rule whatsoever and I really don't know why that is being blocked. I need DHCPv6 for prefix delegation. SLAAC works fine. IIRC it used to work under 2.4.3. After some time of testing I created an explicit rule that allows traffic type UDP to port 547 to the firewall. Eversince then DHCPv6 returned to normal again. I don't think this should be necessary, right? You can find further logs in the attached file. The Forum wouldn't let me embed it. It got marked as SPAM then.0_1539096402880_pfsense_attachment.txt

Thanks There was no existing ipv6 link local address. However after I rebooted the device one was created, so yes it is not needed to manually assign one, the proper solution it seems was simply to add the ipv6 gateway and then reboot for it to be created. As to why there was originally no link local device, I dont know, but this was the first bootup of the device, so I will be aware in future to do a second reboot to get one generated. There is now a possible issue with dpinger tho, after bootup (and wan reset) ipv6 stays pending until dpinger is manually restarted and then it works, the issue that I can see is if I goto the status -> gateway screen, the monitoring ip is not populated, but is populated after the service is restarted. I expect this might be because there is no wan ipv6 configured, the configuration is now like this. WAN ip4 static configuration. LAN ipv4 static configuration. LAN ipv6 static configuration using the ipv6 prefix assigned by hetzner. Default gateways configured using gateways provided by hetzner for ipv4 and ipv6.

@johnpoz said in Working with Temporary IPv6 addresses.: What VPN service support this? I am self-hosting the VPN server. @jknott said in Working with Temporary IPv6 addresses.: @dhiru said in Working with Temporary IPv6 addresses.: I want to route all of the IPv6 traffic on few of these machines through a VPN tunne I assume the other end of the VPN has a different prefix. If so, it's just standard routing. All traffic for the far end of the VPN gets routed that way. Yes. The VPN server is on a different ISP with a different prefix.

The DUID can change for a number of reasons, which is why we added the box to set it static. The DUID is probably what they key static assignments off of, so that's not too surprising to see. So what you probably need to do is see what the DUID is now and then set it to that explicitly, then it won't change again.

@xero9 said in Upgrading 2.4.3-p1 to 2.4.4 breaks DHCP6c?: Not sure if this is related, but after updating to 2.4.4 my IPv6 has stopped working. pfSense gets an IPv6 address on the WAN and LAN side, but no clients are getting an address on the LAN. Probably not. In this case it's a Hyper-V issue and it never gets an address. If you haven't already, start a new thread with as much detail as possible.

I'm on latest Ubuntu. Can ping6 another host in LAN using it's FD... address but not the pfSense LAN. Weird... Found! It seems I need to add separate a firewall rule to allow ULA subnet access the firewall.

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