@Derelict I think it's a CPE issue not Spectrum, but that's just a guess.

@johnpoz said in Can`t get provided /56 prefix: Plus multicast .... Ok, so I'm saved by the fact that DHCP traffic is passed upfront, before the bogon rule list (example). Thanks for the explanation.

just installed a pci network card, and RA is working out of the box :) thank you resolved.

@johnpoz It's a Lenovo E520 ThinkPad. It's whatever driver comes with Windows 10, as I haven't installed any other. It originally came with Windows 7. I just took a quick look and didn't see any I could download.

@tomeq82 well aware that interfaces may be set to prefixes longer than /64 in certain router-to-router links, etc. That is not what is being discussed here. Interfaces with hosts on them need to be /64.

Sounds to me like the ISP has implemented a brain-damaged provisioning. I'd tell them to fix it.

I have pretty much the same kind of setup provided by a local ISP. I found out that ISP providing static IPs is not so common practice. At least among PFSense forum users. I built up two different setup ("automatic" and "semi-automatic"). Not 100% sure those are according to best IPV6 practices, but I tried to do everything by the book. Not just something that happens to work. Hoping you get your IPV6 network to work and/or people here are able to assist you on that. Ax.

@Derelict You cannot SLAAC a routed prefix. Ok, this is clear. There is nothing like that on the configuration page either. You either set it statically or with DHCP6. Yep, done that both ways. Both methods work without issues. You also seem to be confusing assigning an address to a device out of that interface prefix I think I understand that, but that could to be true. The configuration described earlier works and it does what I expect it to do. I don't think it differs much what johnpoz suggested. Ax.

Answering my own question: This post: https://forum.netgate.com/topic/112802/disable-accepting-ra-advertisements-on-an-interface has a suggestion to edit /etc/inc/interface.inc and add a minus ( - ) in front of the accept_rtadv for the WAN interface. This fixed the FC00:: problem. Had to uncheck the "Wait for RA" option in the DHCP6-PD section. Telmex also requires the DHCP6-PD queries to happen over IPv4. A side note: Telmex IPv6 uses a smaller MTU to stay stable. I used 1412 thought 1467 may work as well. Discovered this when ping -6 worked but TLS would have broken/missing packets in Wireshark.

The best thing to do is get information from your ISP. Perhaps they have a beta program or something that would result in more information. You can see what PD you are getting by saving the DUID in System > Advanced, Networking [image: 1566154620163-screen-shot-2019-08-18-at-11.56.41-am.png] Then enable the Debug mode on WAN in the DHCP6 Client Configuration area, setting whatever secret sauce your ISP requires. This is what I use for Cox Las Vegas: [image: 1566154797177-screen-shot-2019-08-18-at-11.59.41-am.png] Your ISP might require something completely different. Then look at Status > System Logs, DHCP and set the filter to process dhcp6c You will see exactly what is happening. My PD looks like this: Sep 1 03:55:10 dhcp6c 44071 update an IA: PD-0 Sep 1 03:55:10 dhcp6c 44071 status code for PD-0: success Sep 1 03:55:10 dhcp6c 44071 update a prefix 2600:dabb:ad00:bc00::/56 pltime=34359824768, vltime=34359824768 Sep 1 03:55:10 dhcp6c 44071 executes /var/etc/dhcp6c_wan_script.sh Sep 1 03:55:10 dhcp6c dhcp6c renew, no change - bypassing update on igb0 Sep 1 03:55:10 dhcp6c 44071 script "/var/etc/dhcp6c_wan_script.sh" terminated If you want to try new settings just increment the DUID-LLT, save, and Edit/Save WAN. That should result in a new renewal using a new DUID so it should all be fresh. Your ISP might have settings that don't like changes like this. Only they know. Ask them. We cannot know what they require here. Again, only they know.

Are the addresses being assigned out of the same /64 or /64s from different VLANs? Perfectly normal and expected for there to be multiple if not several IPv6 addresses on an interface, but they should all be inside the interface prefix. We know pfSense is tagging the traffic properly. The problem is that switch doesn't properly isolate broadcast (multicast) domains or is misconfigured. I would never use one of those switches in any network that mattered to me. I would use it for test stuff (like a tap, as mentioned) or throw it away.

@JKnott Hi, thanks for your response. I'm checking right now the issue with my ISP, seems there are some missing routes that are causing this behavior.

It itself isn't... but the fact is that they're providing a gateway, and unless you put it in Bridge mode, it's acting as a router rather than a modem. So pfSense is getting a single WAN address and no prefix because it's being treated as a client on the gateway's network.

@simonszu said in Firewall VM not reachable via IPv6 on Hetzner: Where is my error? Has my interface config a mistake somewhere? Yes. Here : @simonszu said in Firewall VM not reachable via IPv6 on Hetzner: Currently i have a static IPv6 on my WAN interface, it has the first IP from the /64 subnet Hetzner gave me. On the LAN end i took another IP from this subnet The first IP from the /64 could / should be used on the LAN NIC. For the WAN, you should use some other IPv6 ... as is shown here : @simonszu said in Firewall VM not reachable via IPv6 on Hetzner: https://pratt.is/hetzner-und-proxmox-pfsense-als-gateway/ See the IPv6 page : the guy uses a DHCP6-client setup, certainly not a static WAN IPv6 setup.

@Napsterbater MS is so bad, they work on broken IPv4 too: tbit from 130.217.250.115 to 52.113.64.150 server-mss 1460, result: pmtud-fail app: http, url: https://meet.lync.com/ [ 0.009] TX SYN 44 seq = 0:0 b7ef [ 0.136] RX SYN/ACK 44 seq = 0:1 2774 [ 0.136] TX 40 seq = 1:1 b7f0 [ 0.136] TX 369 seq = 1:1(329) b7f1 DF [ 0.268] RX 1500 seq = 1:330(1460) 277b DF [ 0.268] RX 1500 seq = 1461:330(1460) 277c DF [ 0.268] RX 1460 seq = 2921:330(1420) 277d DF [ 0.268] TX PTB 56 mtu = 1280 [ 0.693] RX 1500 seq = 1:330(1460) 2780 DF [ 0.693] TX PTB 56 mtu = 1280 [ 1.443] RX 1500 seq = 1:330(1460) 279e DF [ 1.443] TX PTB 56 mtu = 1280 [ 2.927] RX 1500 seq = 1:330(1460) 27f7 DF [ 2.928] TX PTB 56 mtu = 1280 [ 5.896] RX 1500 seq = 1:330(1460) 2834 DF tbit from 2001:df0:4:4000::1:115 to 2603:1047:0:2::e server-mss 1440, result: pmtud-fail app: http, url: https://meet.lync.com/ [ 0.009] TX SYN 64 seq = 0:0 [ 0.232] RX SYN/ACK 64 seq = 0:1 [ 0.232] TX 60 seq = 1:1 [ 0.232] TX 389 seq = 1:1(329) [ 0.459] RX 1500 seq = 1:330(1440) [ 0.459] RX 1500 seq = 1441:330(1440) [ 0.459] RX 1500 seq = 2881:330(1440) [ 0.459] RX 80 seq = 4321:330(20) [ 0.459] TX PTB 1280 mtu = 1280 [ 0.470] TX 60 seq = 330:1 [ 1.178] RX 1500 seq = 1:330(1440) [ 1.178] TX PTB 1280 mtu = 1280 [ 2.489] RX 1500 seq = 1:330(1440) [ 2.490] TX PTB 1280 mtu = 1280 [ 5.083] RX 1500 seq = 1:330(1440) [ 5.084] TX PTB 1280 mtu = 1280 [ 10.302] RX 1500 seq = 1:330(1440)

afaik still not possible, openvpn guys are working on it and maybe it will be available for version 2.5 (of openvpn not of pfsense)

macOS, at least, seems to do the right thing: nameserver[0] : fe80::1:1%vlan0 Not sure whether that was received from an RA or DHCP since I am running that segment in Assisted mode (both). You will also have to specifically pass link-local traffic (fe80::/10) to fe00::1:1 tcp/udp port 53 and add fe80::/10 to an unbound access list. Link-local is not considered to be LAN Net so none of it is added automatically when you pass from LAN Net.

@JeGr said in DNS hostname for dynamic IPv6 address: Newer Hosts tend to use EUI-64 if implemented so are not "predictable" by their MAC address anymore Actually, all IPv6 addresses are EUI-64. The host part can be either MAC based, random number or other. With IPv6, the EUI-48 MAC address is converted to EUI-64 by inserting FFFE in the middle and inverting bit 7.